Microservices: hot air or foundation of the future?

Microservices: hot air or foundation of the future?
(Image credit: Pixabay)

As businesses focus on building agility and resilience for future crises, microservices are having their moment in the sun. The success of Netflix and Amazon’s microservices deployments should be a source of excitement for business leaders. But that’s not to say they are a panacea for all business problems. Many businesses may find themselves wanting to deploy microservices without fully understanding what they are and how complicated they can be. Like most things, there is a time and a place for microservices – understanding this is the difference between crippling your IT management team and achieving new levels of resilience.

About the author

Subhash Ramachandran is SVP Product Management API, Integration & Microservices at Software AG.

To understand what microservices are and what they do, you must first understand what came before. For many years, programming revolved around the monolith model. This meant that an entire web page or service was one giant piece of code, split into different tiers (user interface, business logic and data storage). There is certainly nothing wrong with this style of architecture. However, monolith models ran into trouble because of the considerable pressure put on when a single instance of an application was running in a production environment. All clients, whether they were humans or systems, communicated with that one application server.

What this means in practical terms is that a single coding error or uncoordinated update would take down the whole system. This was manageable back when companies deployed new code once a week or even a month. However, it simply wasn’t acceptable by the time companies such as Amazon were deploying a new piece code every second. The need for agility and multiple teams working on a single program has meant a new architecture is now required to remain competitive.

Microservices to the rescue

A microservice is a service with a single purpose and is fully self-contained. A classic microservice has a single development team and manages its own data. It uses events to interact with other services to avoid tight dependencies - and supports fully automated deployment and monitoring. Because of its independence, it can be replicated easily for scalability. It can also be modified on its own schedule; there’s no need to coordinate with a release timeline for other services on the same platform. It can be developed in any language.

Microservices are ideal for a distributed cloud environment, since they can take advantage of cloud services which can spin up new machines in seconds. With automated deployment, a service that’s in demand can be replicated dozens of times in a matter of minutes. The independent nature of microservices also encourages faster revision cycles. This freedom enables business units to innovate quickly – fail fast – to uncover new opportunities. It also enables complex systems to be decoupled so individual capabilities can evolve at the appropriate pace.

A useful way to picture this is in a restaurant. Here, a microservice could represent the kitchen supplying the food. But it could also represent a narrower segment – the sandwich supply service. So, if customers order more sandwiches than expected, a new sandwich kitchen (or three) can start up to handle the traffic. This enables the kitchen to allocate resources – both people and food – in a precise way to meet the needs of the customers.

Managing the sandwich supply as a separate service also has other benefits. The sandwich supply service can try out new sandwiches and adjust old ones without needing to coordinate with anyone. It can hire sandwich experts to create the sandwiches that are of higher quality. This enables the restaurant to create unique and desirable sandwiches faster, just as an independent microservice can evolve faster to drive competitive differentiation.

Not a panacea

Many business leaders are likely to read this and go away thinking that microservices are the answers to their prayers. But, as any IT manager will tell you, it’s not quite so simple. Without being properly managed, microservices run the risk of becoming a disorganized, tangled mess of connections like the spaghetti code of the early 2000’s. Furthermore, while distributing solutions across a microservices architecture may happen in a snap, issues and vulnerabilities can creep in just as easily.

Put in the context of the Gartner hype cycle, business managers are flying high in the “Peak of Inflated Expectations,” while IT managers are working their way out of the “Trough of Disillusionment.” The problem is that when IT managers inject a dose of reality into business leaders’ expectations, they are often accused of being pessimists. But is it really that case? Instead, they may be the pragmatists, the realists. Instead of holding microservices projects back, they may be the only chance of making sure those projects don’t spin out of control. In fact, keeping microservices under control is so hard and so important that you may need an entire platform to manage them.

This is not to say that firms should neglect microservice opportunities completely. No architecture is perfect, whether it is monolithic or broken down into numerous tiny services. At the same time, however, you don’t need to pick just one or the other. Distributed architectures, which offer both the simplicity of traditional monolithic models and some of the scalability of microservices, occupy a nice middle ground between the two ends of the spectrum.

Are microservices for you?

Even if microservices aren’t for every situation or every company, they are already an indispensable part of the enterprise IT world. The pressure to reduce time to market is becoming more acute every day, especially amid the uncertainty of the pandemic. Now is the time for firms to do their research and figure out whether microservices are right for them.

Subhash Ramachandran is SVP Product Management API, Integration & Microservices at Software AG.