The key to evaluating the usefulness of a microservices (MS) IT architecture is to have a good understanding of the customer’s context, business, processes (operations, IT, product and systems lifecycle, etc.), existing technologies, and expectations (long-term stability vs. high dynamism, agility vs. long-term planning, etc.).

The following is a summary based on the successful implementation of such a project (or several related projects), where the customer’s readiness and commitment played the primary role, the proper selection of key players, and the flexibility that must be considered at each implementation stage.

What are these microservices?

IT architecture can be built using different strategies and approaches. Of course, it depends on the context—who, what, how long it should serve, the expected life cycle of the systems being built, etc.

Microservices are one of the architectural styles. They are based on the idea that we build systems out of small (relatively small) autonomous components (as little dependent on other systems and components as possible). A typical microservice should be able to be programmed in a few days, weeks at most, have its database and communicate with other services (if necessary or desirable) in the “lightest” way possible – e.g. HTTP REST. Since they are small, there will be many such services, so deploying and managing them automatically is advisable.

In return – and this is the primary motivation for using this approach – we gain significant benefits:

• clean architecture – “strong boundaries” of individual components, explicit and clear interfaces and competencies
• independent deployment – if I (re)deploy only a small change, I have less risk of messing up something else
• lower dependence on technology and vendor lock-in – such services are independent and can be delivered by different technologies and vendors
• scalability – the ability to scale in width just and only those components that are the bottleneck and nothing else

On the other hand, the IT architect must also be aware of the risks and drawbacks of such an approach:

• Distributed – more independent services = higher degree of distribution = more complex program
• Eventual consistency – more databases = higher risk that, at a given moment (still or already), the data are not consistent with each other (even if only briefly)
• More complex operational activities – I do not supply the operation with a “system” but with a set of “components” that the operation has to take over, deploy and keep running; it’s like Swedish furniture – I supply components that the customer can – but also has to – assemble into the whole that he needs.
• Performance – communication between microservices is usually “more expensive” than internal calls within a monolith; the risk is especially evident if the granularity (size) of the microservices is inappropriately chosen or the boundary between them is not chosen correctly

Either way, the criteria for using this architectural approach are clear – I will use it when the benefits outweigh the risks, which an experienced IT architect, with knowledge of the customer context, should be able to estimate and calculate.

What did the customer need to solve?

We recently successfully helped a customer overcome a technology and structural issue in their sales and customer systems by gradually transitioning from monolith to microservices.

His agenda included selling services and goods in branches nationwide, operating an e-shop, providing electronic services to end users, and handling everything related to customer care (self-care, call centres, etc.).

However, all systems ended (or started) in a large and relatively complex (and therefore expensive) system that, while reliable, was already at its limits – costly and risky changes, performance concerns, overpriced operations and development, etc.

So, the typical motivation initially was that we had an old, expensive, and slow monolithic system with costly licenses. Increasing performance by scaling up was already virtually impossible, and more powerful hardware no longer improved performance. Changing the architecture of the solution meant doing it all over again.

The customer was aware that the remedy was only possible by changing the approach to the solution, not just replacing one box with another.

Analysts and designers have correctly assessed that different system parts have different lifetimes, change dynamics, performance requirements, and scaling behaviours.

The IT world has changed recently, so developers and other specialists have different expectations regarding technology and methodology. Drilling into a monolith they will not meet anywhere else does not add to the feeling of meaningfulness.

So, the decision was made to gradually dismantle the monolith and replace it with multiple independent applications organized within a service-oriented architecture. The only remaining question was their granularity—a few main applications or many small autonomous services.

In the end, the view that “something like this and something like that” prevailed, depending on how much helpful performance each domain would offer and what kind of decomposition its data would allow—because the distribution of monolithic data (the database) is the touchstone of any attempt at a strongly distributed architecture (of which MS is an extreme case).

Why did we recommend microservices to the customer?

It is essential to realise immediately that multiple groups within the customer have different requirements and expectations of the system: operations, business, operators and assistants, call centres, or marketing. Of course, shop and store customers come into contact with the system differently, at different times, and for other purposes. Satisfying (and reassuring) traffic is no less important than meeting marketing’s expectations.

Therefore, we considered all the implications of the newly proposed approach (architecture) – from system development and evolution through its deployment for testing and operation to its retirement or gradual replacement. It is also clear that no requirement is final, that in a few months and years, everything may be different and that the system will have to adapt – to other parts of it at various speeds and in multiple dimensions – functionally, performance-wise, user-wise.

Therefore, we declared the main advantages of the proposed microservice architecture (for most of the system) to be:

• Sequencing and continuity mean the system will be delivered sequentially, piecemeal, on the fly, i.e. alongside “business-as-usual.” No BigBang, nobody will risk. The scope and speed of delivery can be continuously regulated according to development capacity and customer priorities.
• Scalability = small autonomic services are ideal for scaling; other architectural approaches hardly match this aspect
• of independence = flexibility. No vendor lock or technology lock. Each microservice or micro application can be replaced (re-implemented) in a few weeks (on the order of weeks) regardless of technology, framework, or vendor, as MS are autonomous. The only condition is to comply with the integration interfaces.
• Stability = a possible error, failure or other deficiency in one part of the system (one microservice) affects the whole to a much lesser extent than a monolith (which either runs or stands still), but also as a “layered” service-oriented architecture (in which problems can propagate within a single layer across multiple domains)
• Low cost for small and medium changes means it’s easy to understand how individual microservices work and make a change/repair without the risk of damaging something I don’t even know exists. This has a direct impact on independence—I don’t have to deal directly with unrelated parts of the system because all possible links and contexts are explicit (via interfaces).

How long did the implementation take?

The measure of a successful project is, among other things, the duration of the implementation because time is money and prolonging a project is equivalent to making it more expensive. But the seemingly simple metric – how long the project takes vs. how the milestones were set – has its pitfalls. In this case, the work to transform from a monolithic system to an MS architecture was estimated to take three years. However, it was clear that at that time, the implementation team would have to absorb a non-trivial amount of changes and work that was not in the plan:

• Changes in marketing and business (the world is changing, and business must reflect this because sales must not stop)
• Legal must — a change in legislation is not signalled in advance and cannot be postponed. We have experienced GDPR, eCash, and a suite of other changes that needed to be incorporated as part of the transformation without delaying, cancelling, or pushing it back.
• Licensing and technical constraints—During the project, business and licensing terms, versions of tools and frameworks used, support for existing and planned components, new security threats, and recommendations for their elimination have changed. But these are the risks of any not-quite-short project.

Despite these influences, the project reached its final form on time (the deviation was tens of days).

Why are microservices companies worth it?

A company that builds (or has built) a system for its core business usually has specific expectations regarding its functionality, reliability, and cost.

But the total cost of owning that system, using it, maintaining it, and replacing or modifying it incrementally or in fits and starts – that’s where the estimates are very imprecise (and there are objective reasons for that). The decision to adopt a new system or make a significant change to an old one requires predicting how the company, its customers, and its business will evolve. Monolithic systems usually induce decisions over a long period. It will last a long time if I go for it, and changing the decision will be expensive. Building a system in smaller – but cooperating – parts has its risks (I have to make decisions on an ongoing basis and evaluate what to do next). Still, I can change or fix each decision relatively cheaply and quickly. The higher the level of uncertainty I need to incorporate into my plans, the more worthwhile it is for me to invest in a scalable, malleable architecture for my systems.

Highly dynamic industries such as telco, energy, media, and anything on the internet today are no longer taking risks. They are opting for an approach where everything can be changed and replaced by the next tax year.

Microservices – is it the future?

Today’s world – revolving around technology – is very fast. Ideas are being recycled, but their use has become so fast and cheap that it has changed the basic principles of building a business – not just in the technology or IT domain.

Reality dictates that change needs to be made today, tried and fixed tomorrow, or thrown away. Change = no waiting. MS, as an architectural approach, caters to this philosophy—do something quickly, albeit easily, and change it shortly (even completely redesign it) if it doesn’t go well. And vice versa—if it’s good enough, don’t mess with it (don’t do extra work = don’t waste time).

All of MS’s above-described advantages point to precisely this—maximum flexibility, easy scalability, portability (=independence)—they allow the company to make these changes quickly, with little risk, and to react to changes in external conditions (market, technology, suppliers) and internal needs and expectations (going to the cloud, multiplying resources by order of magnitude, changing the scale of your business, etc.).

So yes, microservices are the future and already the present.

If you have any questions or want to consider using microservices in your business, please do not hesitate to contact us.

Rastislav Senderák, Architect