Beauty of #microservices - making them practical

The classic definition of the microservice architectural style “as an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanism” creates a lot of fears and misunderstandings:
  • Application monoliths are evils, but having too many microservices sounds like creating an (unknown) evil as well.
  • Everything has to be re-developed.
  • Microservices will create a huge backlog for our agile team.
  • Microservices? They are neither architecture nor architectural style – just a technical stack.
As usual in IT, any new technology or methodology (which pretends to revolutionized everything) must be used together with many existing ones. Let us “intermix” MSA with some existing and proven technologies and methodologies.

MicroService Architecture (MSA) bring two major concepts:
  1. microservice as a unit-of-functionality, unit-of-deployment and unit-of execution with the same boundaries, and
  2. assembling a whole application from microservices of different origins: off-the-shelf (commercial and FOSS), brought, rented, built, provided from SaaS, PaaS, APaaS, etc.
Using these two concepts, let us try to find a practical balance between monolith architecture and MSA.

Firstly, it is necessary to think about any application as a set of the following artefacts
  • Events
  • Roles (actually, access rights management)
  • Rules (or decisions)
  • Business objects – data structures
  • Business objects – documents
  • Human activities (or screens or interactive services)
  • Automation activities (or scripting fragments or automation services)
  • Coordination
  • Audit trails
  • KPIs
  • Reports
Secondly, consider that each artefact must be, ideally, handled
  • Explicitly
  • As a set of microservices
  • Via APIs
  • With versioning 
  • By a specialized OTS tool, e.g. data structures are handled by a database, processes are handled by a BPM-suite tool
  • In a Domain Specific Language (DSL), e.g. BPMN for processes, DMN for rules
  • Over its whole life cycle
Thirdly, understand specialised tools for that each artefacts:
  • Coordination as explicit and machine-executable processes via a BPM-suite tool
  • Roles via an access management tool
  • Documents via an ECM product
  • Automation fragments as scripts in an interpretive language and execution robots
  • Audit trail and reports via BI tools
  • etc.
Fourthly, prepare two common “pool” for future tools, services and microservices:
  • technological pool for generic off-the-shelf products; their functionality is available via APIs
  • enabling pool for services, microservices, tools which are a) specific for the particular organisation and b) potentially reusable within organisation; their functionality is available via APIs
For each monolith application, sort its functionality out into 2 common pools and an individual pool.

At the result, we got a corporate unified business execution platform which standardise and simplify core elements of the corporate-wide computing system. For any elements outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing:
  • The platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform.
  • An agile approach requires coordination at a system level.
  • To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives.
  • Existing elements of the platform also need periodic challenge. Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.
Obviously, do not forget to the a good application architecture - http://improving-bpm-systems.blogspot.ch/2017/05/beauty-of-microservices-ebanliing.html and http://improving-bpm-systems.blogspot.ch/2016/08/better-application-architecture-apparch.html


Other blogposts about microservices - http://improving-bpm-systems.blogspot.ch/search/label/%23microservices


Beauty of #microservices - enabling #BizDevOps culture

Everyone heard about the DevOps culture which refers to a set of practices that emphasize the collaboration and communication of both software developers and IT professionals while automating the process of software delivery and infrastructure changes.

Certainly, DevOps improves the time-to-market for digital solutions, but it spans only a down-stream part of the idea-to-solution value stream. To cover the whole value stream, any up-stream stumbling blocks must be removed.

An application architecture, which is built on microservices and their machine-executable coordination (e.g. by processes), enables a new BizDevOps culture by quick implementations of business ideas. (I think that ING has introduced the BizDevOps concept).

Microservice is a service with the same boundaries as
  • a unit-of-functionality (for Biz)
  • a unit-of-deployment (for Dev)
  • a unit-of-execution (for Ops)
Thus, an implementation of a business idea as a group of microservices will have no unnatural complexity and, therefore, its time-to-market will be short.



Other blogposts about microservices - http://improving-bpm-systems.blogspot.ch/search/label/%23microservices  

Beauty of #microservices - adding ASSEMBLE to BUILD or BUY or RENT

MicroServices Architecture (MSA) is changing the classic Buy or Build or Rent question.

With MSA, orgnisations may use an extra option - Assemble. This allows an organisation to select the best option for each service or microservices. For example:
  • Buy services and microservices from organisation's business partners
  • Build microservices for organisation's unique capabilities
  • Rent services and microservices from the commodity markets
  • Assemble all services and microservices into organisation's unique solutions


Other blogposts about microservices - http://improving-bpm-systems.blogspot.ch/search/label/%23microservices


Beauty of #microservices - #microservice architecture maturity model

This blogpost is inspired by the discussion https://www.linkedin.com/feed/update/urn:li:activity:6266622261210411008/

I can imagine an MSA maturity matrix:
  1. atomic microservices 
  2. compound microservices (a microservice with wide single responsibility is built from microservices with narrow single responsibility) 
  3. data-entry applications in MSA (interactive microservices, validation microservices, persistence microservices) 
  4. process-driven applications in MSA (coordination microservices, management microservices, etc.) 
  5. all former applications in a value-chain are in MSA(actually, no boundaries between applications)
  6. all former applications within an organization are in MSA
  7. all former applications in a supply-chain are in MSA
  8. all former applications in an ecosystem are in MSA

Please, see my blogposts on #microservices http://improving-bpm-systems.blogspot.it/search/label/%23microservices