Welcome to Part 4 of the Cloud Native, Microservices, Security, & Scale Series.
In the last two posts in this series, we took a look at the changing needs of the modern enterprise – including the need to be able to innovate much more quickly, while keeping their ability to stay secure, scalable, and resilient. We also looked at the challenge of being cloud native – or building services to fail, and realizing that while your infrastructure is an incredible asset – it can also be one of your biggest threats.
This means that we not only have to change the way we build our infrastructures, but the very way we build our applications. Moving away from large monolithic systems that do everything except make coffee (well, some even do that), to tinier, autonomous systems that are more agile.
Thus the concept of Microservices, which expands on (or depending on which camp you reside, perhaps replaces) SOA was born. Like SOA (or Service Oriented Architectures), Microservices are smaller services within a larger architecture. In the case of having a shopping cart – you might have a cart service, a shipping service, and a payment service. Each service is really it’s own separate application – hosted on its own server (or in the cloud), abstracted by its own API, and operated independently of the other services.
But instead of relying on SOAP (Simple Object Access Protocol) APIs as you would with SOA, Microservices instead rely on newer models such as REST (Representational State Transfer), RPC (Remote Procedure Calls), GraphQL, and other communication abstractions.
The idea behind Microservices is simple: let small teams develop autonomously, utilizing the skills they are best at, and allowing their application or service to evolve independently of the rest of your architecture.
The challenge, however, of moving to a Microservices infrastructure – may not be as simple.
“When you start to dig into it, running multiple services for specific functional areas of the application becomes quite challenging. You have to embrace things like [remote procedure calls]. While that might not seem like a particularly heavy lift effort at first glance, it does require that developers start considering things like network latency and network stability. It’s not just method calls within a single process.” – Dave Riess, CTO, Wunder
Not only are there these “hidden” costs, although similar to what is already being done with SOA – you also run into other challenges, such as what exactly makes a service micro (vs just another service), where do you divide up your services or applications, and even the challenges of implementing a communication layer (latency, versioning, etc). Some of these challenges which we’ll look at, and address later on in this series.
Because, if you don’t, you will fail to exist. Perhaps not, but for all the challenges that transitioning to Microservices present, they offer significant advantages – most importantly – they allow enterprises to not only be innovative – but to innovate at speed, with scale, isolation and increased security, and resiliency.
And while you may not choose to take advantage of these (and hypothetically significant operational cost savings in the long run), I can promise you that your competitors will.
Because Microservices are setup autonomously, meaning that each service lives in its own space, and acts independently of any of service (outside of potentially consuming some APIs) – developers are free to use the languages and skills that they are most comfortable with. More importantly, because changing a class or method doesn’t hold any impact outside of the smaller application – changes can be completed quickly without significant risks to the entire infrastructure.
Beyond changes to an individual service, a Microservices Architecture, if properly setup, will even let you remove and replace individual services themselves with no consequence – enabling easy transitions from older services or technologies to newer ones.
This also means that developers do not have to know, or even understand the entire architectural stack. They do not have to understand how applications using their Microservices’ API are setup nor designed. The only concerns they have are that their service functions properly, is efficient, and that the API was designed to act as an appropriate interface.
This means that they can develop fearlessly. More-so, they can specialize in their Microservices architecture and code, and being a smaller service have less code to navigate – and less aspects that require testing.
Also, being composable, Microservices make third-party application development faster as well. Rather than having complex integrations, third-party developers, or those integrating the service in with their own can simply call a REST API – using a uniform interface such as JSON as the language mediator.
While there are concerns around usage and latency – Microservices offer significant benefits in terms of scale. The most notable is that because Microservices are isolated, as usage of the service grows – you only need to scale that service – not an entire monolithic application. This means that you are actually able to scale more quickly, and at less cost.
» Isolation and Security
Microservices also offers a smaller attack surface for any potential breaches. While application security is critical, breaching into an isolated Microservices limits a hacker’s ability to infect or manipulate the rest of your applications. The attacker can certainly wreck havoc, but their reach is limited by the capabilities of the Microservices’ API.
This means it’s also easier to protect sensitive data by limiting what data can be exposed through the APIs, and ensuring that if a different service is breached they do not have access to the other more critical services or the data storage/ system layer (ie access to the actual database itself, as long as it too is properly abstracted).
One lesson I learned as a young child (back in my “Superhero” days) is that it’s a lot easier to move a chair than a house. The same is true with Microservices. By taking advantage of technologies such as containerization and Kubernetes, you can create self-healing services that restart on failure. Being limited in scope, this smaller service becomes much easier to restart than having to restart a complex and tightly coupled monolithic application – that may make use of numerous message queues and transactional setups.
When issues arise, again they are in isolated areas within your architecture, and require a small reset or patch – allowing the rest of your architecture to continue running without (or with very little) impact.
However, while Microservices offer many advantages – they are not a fix all – nor is it an exact science. Instead, Microservices require careful planning while introducing new networking and management challenges.
And if implemented incorrectly, not only is your company likely to struggle in terms of managing these services, but you could very well suffer the same fate as SOA – large entangled applications that companies are now spending hundreds of thousands to millions of dollars trying to untangle.
The sad reality is, that while Microservices expands upon SOA – and offers many significant advantages and a new way of thinking – it also shares many of the very same similarities.
Next week, we’ll address these similarities and differences to gain a better understanding of the Microservices approach, followed by how to avoid the “Glue” problem – or the application entanglement that crippled SOA.
Get updates on blog posts, new releases and more!