In a world of rapidly evolving technology, senior execs and tech decision makers are always faced with the same questions.
Adopt? Adapt? Or leave this one for later?
In the last decade, this has been truer than ever, with a huge upswell in new cloud technologies under the broad umbrella of ‘cloud native.’
These more scalable, flexible and adaptable technologies are increasingly touted as permanent replacements for traditional cloud, with some seeing this shift as on par with that from on-prem to virtual machines.
But what unites these technologies? And what makes them so powerful?
Let’s consider the pros, cons, and best use cases of microservices – but for a little context, we’ll make a brief stop at the wider world of cloud-native tech.
What is cloud native?
Cloud native is a catch-all term. And there’s no single definition. What people usually mean, however, is something that’s been developed wholly on cloud, and that leverages cloud technology in every aspect of its design.
In practice this usually means it…
- Uses declarative programming
- Uses containerised, serverless and/or microservices-based architecture in place of ‘traditional’ cloud architectures
What technologies are often thought of as cloud-native?
Serverless
Serverless breaks from traditional cloud in that applications are broken down into pure business logic, and then servers are supplied on-demand by an orchestration tool. This means, instead of being provisioned by a cloud architect, they’re spun up automatically per request.
Containers
Sometimes thought to be the ‘missing link’ between VMs and full serverless, containers are essentially VMs with one less layer of virtualization. Think of them as streamlined VMs.
So what about microservices?
Microservices is a programme architecture approach in which the application is split into a series of smaller, modular services, i.e microservices.
This differs from a traditional monolithic approach in that each of these services can be easily separated, altered and replaced without affecting the others.
Or to put it another way, a monolithic architecture is a train, while a microservices architecture is a convoy.
If we take the example of an e-commerce page, we can imagine that the search function, payment portal and image carousel are decoupled, allowing us to scale, refine or swap out the payment portal, for example, without changing anything about the search bar or carousel, and vice versa.
And as you can imagine, this can be extremely powerful.
The pros of microservices
- Selecting from best of breed services
Because each service is selected independently, you can choose the best breed for each.
- Specialisation within teams
The smaller code base allows your team to fully master the service(s) they’re responsible for, making it easier for them to refine and augment.
This is complimented further by the fact that each service can be tweaked without disturbing its neighbours, granting teams the autonomy and specialisation to drive their service forward.
- Independent scaling/deploying
Each microservice can be deployed and scaled independently.
In the case of scaling, this equals flexibility and cost saving, as you can scale only the service that needs it.
For deployment, this means adding new features faster and with less risk.
- Easier to isolate faults
Because each service is self-contained, it’s easier to identify failure areas in the event of an outage.
But as with anything, there are drawbacks, too.
The cons of microservices
- Problems with overall orchestration
Coordinating resources and teams can be difficult, especially for small companies.
More microservices means more databases, more teams - who do have to sync up to some extent - and more deployments.
All of which need to be managed carefully.
- Debugging
Each service will have its own log, making debugging a much meatier task.
- Cultural requirements
You really need to have a DevOps culture in place to work with a microservices application. Without that, the kind of cross service collaboration required just won’t happen.
- Expensive to start
Although microservice-based applications are cheaper once they’re up and running, they’re costly and time consuming to architect.
Who should use microservices, and who shouldn’t.
To put it as simply as we can, microservices are complex, but they solve problems - so if you haven’t got those problems, don’t take on the complexity.
Microservice architectures work for large mature teams with healthy DevOps cultures in place. You need to have enough people to cover each service, and the skills to take advantage of the scope for specialisation.
You also need the overall coordinating ability to liaise between teams, and manage the logs debugging, deployments and more.
And that’s just to see whether you can adopt microservices.
Whether you should depends on if you’ll benefit from the core features.
For instance:
- If you have a legacy application which is being held back because you can’t add new features easily
- If your application runs a lot of naturally separable processes, like a video or banking platform
- If your business model means you’re always going to be trialing and swapping out new features, like a social media platform - then a microservices approach is right for you.
However, if you have a brochure website, the ends don’t justify the means.
In essence, the cost of microservices is that they tend to spiral out in terms of complexity, so if you’re not getting a lot out of the pros, it’s best to stick with a monolith.
Freddie Heygate is the CEO, Asia for Just After Midnight. He and his team support global brands and agencies such as across the region to deliver critical round the clock support, managed cloud and DevOps consultancy.
