Martin Fowler described the concepts of microservices in 2014 and the adoption of microservices in both large and small enterprises has been growing. Some estimates in 2018 show that 63% of enterprises are using microservices and another 28% are considering migrating some applications to microservices.

Companies are adopting microservices in mass and many are also failing at it. This is a reality check for companies seeking to further their digital transformation. Those companies are not incompetent — most successfully navigated major architecture transitions, from centralized mainframes to distributed client/servers to the Internet to the cloud. What happens is that the next transition, Cloud Native, is hard — intrinsically so.

It is all about the business

Many companies fail to understand the business needs that microservices architectures address. There are several. Let’s discuss the two that are core to the microservices approach.

The first business need is agile software delivery. On the one hand, software is increasingly becoming a key part of products and services. The Internet and the cloud enabled new digital services distributed through new digital channels. Nimbler competitors have exploited those channels to compete against established players and deliver innovative services faster.

Customers’ expectations have changed as a result of these trends: they are used to customized products, services, features delivered where they want them, in the channel of their choice, at any time of the day. They may defect to competitors because of the absence or presence of a single feature.

Do you really need microservices?

Microservices empower you to scale components independently. In Istio 1.5, control plane costs are dominated by a single feature […] Every other feature has a marginal cost, which means there is very little value to having those features in separately scalable microservices.

Microservices empower you to decouple versions and release different components at different times. All the components of the control plane have always been released at the same version, at the same time. We have never tested or supported running different versions of (for example) Citadel and Pilot.

Microservices are complex distributed systems

The essential complexity linked to microservices is that they form a dynamic distributed system. What was 1 cohesive large application (monolith) may now be 15 independently deployable, loosely coupled, smaller microservices. You now have to program against partial inter-process communication failures or exceedingly high latency between services.

With instances of services dynamically brought up and down, you need either location transparency or discovery services. You need to minimize calls between microservices to decrease latency or you end up with a less responsive application.

You still need to implement transactions and queries that span multiple services. But now your database is distributed across microservices. How much of ACID can you keep without sacrificing performance? You also must secure your distributed application against new classes of threats. The list goes on. And none of the items are going away.

Beware anti-patterns

Distributed Monolith anti-pattern (part of the Monolithic Hell family) occurs when a monolithic application is broken down into multiple single-instance services — but most services remain tightly coupled.

A distributed monolith, as opposed to single-process monoliths, is an application distributed over several processes but built like a monolith. You get to have separate teams maintaining smaller pieces of the monolith but the motivating architectural drivers that we mentioned at the beginning of this article are absent. Microlithic systems are neither scalable nor resilient. The entire system often has to be deployed together. You get the complexity of distributed systems, the disadvantages of monoliths — and little to show in exchange.

What leaders do?

Many companies have successfully and progressively completed their migration to microservices with the Strangler pattern. Keep your monolith, start small with a selected few microservices (as few as one), put a strangler facade between your monolith and your new services. The strangler facade redirects some of the requests to your new services while continuing otherwise to use your existing monolith. As you add more and more services, your legacy system is less and less solicited.

Migrate progressively from a monolith to microservices

This of course creates other issues that do not appear with synchronous request-driven models. Events may be sent and never received. Event consumers may be down or not available. Events can be duplicated. The good news is there are other patterns that have emerged that address these issues. To cut a long story short, these are the most important patterns covering the whole software delivery lifecycle that you must be aware of and that will drive the performance of your microservices implementation:

Leaders deliver features several times a day to production, detect and recover from failure in a few minutes — with no downtime perceived by the end-user. They optimize cloud spend while maintaining quality of service by automatically scaling up and down without monopolizing site reliability or DevOps engineers. Every one of these patterns has a reason to be.

How CodeNow facilitates all this

Microservices are harder than you know. We made our DevOps VSDP CodeNOW so that you can train the staff that you already have to the concepts, principles, and patterns that drive elite performance in software delivery. CodeNOW provides a sandbox environment in which Dev, Ops, DevOps, SRE teams can learn on a real cloud. We know from our experience while creating CodeNOW how difficult it is for developers to deliver high-availability-, disaster-recovery-friendly event-driven architectures on your notebook or with a single VM available.

CodeNOW users learn concepts, principles, and patterns. Concepts, principles, and patterns last, technologies come and go. We want you to focus on your business. Talk to your customers. Craft the digital services that address your customers’ needs, innovate, distribute your products to new channels. That is what your business is about. We handle the software delivery for you. We help you move from customer needs to delivered features.

Source: https://www.codenow.com/blog/migrating-to-micro-services-harder-than-it-seems