A Microservices Primer

The technical definition is….microservices are design patterns to turn complex applications into simple, fine-grained, reusable, and interoperable processes that can be modified and deployed independently of each other.

Ok, a bit heavy…so let’s translate that, using some mental visuals.  Imagine you’re 30 years in the future and you have a great family home, Jetson’s style (for those of you who don’t know the Jetsons, pause here and go google it). 

You’ve got your spouse, two kids – Elroy and Judy, a dog – Astro, and of course, Rosey, the robot maid.  She’s awesome….truly.  She does EVERYTHING around the house – cleaning, laundry, dishes, and even cooks for the whole family.  For safety and her convenience, all of her tools for her activities are locked, using near field communications technology to unlock items as she needs them to accomplish her goal.

Life is good with Rosey – even though she’s not the latest model, she represents the best that the XB-500 series offers.  But one day, she has to go in for an upgrade to her system.  Acme, Inc comes to your home, picks her up, and takes her away – promising she’ll be back, better than ever, in just two short weeks.

So, let’s think about that….Rosie did your cleaning, laundry, dishes, and cooking.  And she used NFC to unlock the cleaning cabinet, laundry room, dishwasher, and the fridge.  AND she’s gone for two weeks.  Your home life is officially on hold.

Now hold that thought….let’s come back to the present time, and think of ants.  Yes, ants.  Think about it….ants generally are doing one of two things – hunting for food to feed the colony, or protecting the colony.  Now, a hunter ant is out foraging, finds some rice someone spilled, sounds the alarm, and BOOM – you’ve got a line of ants carrying rice to the colony for a great dinner.  So I come along…and, well, forgive me PETA, but I step on a few of those ants.  Now…does it make a difference?  Well, I mean, it does for those ants….but for the overall goal of feeding the colony?  No, not at all.

And THAT’s the value of microservices.   Traditional monolithic applications can be huge, provide tons of value, and do lots of different things…like Rosey the robot maid.  BUT….it can be difficult to add additional functionality without breaking things, meaning it can be a real chore to innovate.  And when there IS an upgrade or update, it takes some time…and during that downtime, anything the app did is…well, down. 

But, with microservices, I’ve got a whole bunch of different services running.  Collectively, they may perform the exact same functionality as a monolithic app.  But since each service is independent of any other service, pieces can be updated or even upgraded on the fly, without impacting the app – other than that small piece.

Make sense?  So microservices are small – very small, very focused.  They are messaging enabled, to be able to pass information back and forth.  They are independently deployable, and decentralized.  They are language agnostic….so you can have a team using Python to create a service, a team using C++, a team using Ruby, and a team developing in Java…and these services seamlessly work together!

To be fair, when you have a bunch of small services being developed by a bunch of different teams, then the initial software architectural design time likely will increase.  And a whole lot of moving parts means you really want to monitor everything going on.

With the latter in mind, these services are deployed in a Docker container, providing a centralized runtime environment – although you can have many Docker containers.  A side benefit of using Docker containers is that it eases the management burden.

Ok….that’s a microservice….so why are they so important? 

Well, you’ve probably heard of the app economy – pretty much what much of the world is now living in.  And every digital enterprise trying to thrive in the app economy is typically aspiring for two things – their mantra: speed and scale. If a company’s need to get to market faster is critical, it’s equally important to be able to scale up appropriately to support increasing customer demand.

But the key mantra modification you need to make is: speed and safety at scale. You can only succeed when you attain that speed and scale without losing safety.

Also, in order to intelligently break down complex, monolithic applications into small autonomous units, you need a design strategy, namely, a microservices architecture.

By breaking your huge application into microservices, you’re enabling your development team to be more nimble with updates and autonomous deployments. This removes dependencies to create large and complex builds, and it eliminates the need for over-sophisticated architectures to step up scalability to meet volume demands.

Ok, now you may be wondering if microservices are right for you and your enterprise.  A good question.  And, once again, my favorite answer…it depends. 

Every enterprise has different needs – and there are definitely times when microservices are a good pattern to provide a solution, and there are likely times when a monolithic application may be more appropriate.

Monolithic applications are generally easier to build – initially…and (again, generally) are easier to test against – initially.

However, monolithic applications are more difficult to maintain as your codebase grows, slower to iterate as time goes on due to the growing codebase, and can be difficult to scale, as infrastructure generally has to scale for the entire application, even if it’s only one component of the application that is having scalability issues.  They’re also more difficult to innovate with, as you have that codebase at the root, and difficult to insert new programmers against, as there is a steep learning curve, again, due to that codebase at the root.

So….back to the question…are microservices right for you and your enterprise? 

Well, there’s a few things you need to evaluate:

• Have you adopted DevOps?
• Do you, or can you, create multiple small teams of developers?
• Can you break down your current, or new, application into simpler services based on capabilities or functions?

If you can say answer “yes†to these, then you may indeed be ready.

Which means, you’re still listening (whew!).  We’ve talked about what microservices are, and why they are becoming so important.  Now let’s talk about implementing microservices, as well as touch on APIs and API Management – turns out they are crucial to a microservice architecture.

Just a quick note – while you may see microservice and microservice architecture used interchangeably, they are not quite the same.  A microservice architecture is a style of engineering highly-automated, evolvable software systems made up of capability-aligned microservices.  In layman terms, microservices are a key component of a microservice architecture – as are APIs.

Think about it…microservice components only become valuable when they can communicate with other components in the system – and to do that, they each have an interface, or API, for that communication. Just as we need to achieve a high level of separation, independence and modularity of our microservice code, we need to make sure that our APIs, the component interfaces, are also loosely coupled. Otherwise, you won’t be able to deploy two microservices independently, which should be one of your primary goals to balance speed and safety, as we discussed.

An API layer in front of microservices provides the support for client side applications (such as mobile) as it isolates the fine grained microservice from the app. This layer is ideal for doing microservice orchestration and to apply security. 

And THAT is why an API gateway is so crucial – it provides centralized security enforcement for authentication, authorization and threat protection,…routing and mediation to protected resources across various protocols, and service level management for enforcing business-level rate limits and quotas.  A gateway also enables service orchestration and enables exposing application-specific interfaces to monolithic back ends.

The gateway applies security on behalf of microservices, and provides the integration into existing identity management systems – even enabling SSO.  However, there is also typically an OAuth provider that manages security sessions that is both tightly integrated with the API gateway and is working side by side with that gateway.

So…we’ve covered most of the pieces you really need to implement a microservices-based app – microservice design, development, and deployment. We’ve talked about how key an API management solution is to complete your microservices architecture. 

The last piece you will need is a monitoring and management solution for your microservices.  As I mentioned, this new architecture has a lot of moving parts, and it’s important to have an automated solution that can manage your Docker containers and the components of your services and apps. 

So I’ll wrap up with a last thought…..today’s DevOps and agile-loving enterprises are striving for fast changes and quick deployments. To these companies, the microservice movement is a boon, but not a silver bullet. Organizations can enable smaller development teams with more autonomy and agility, and as a result, the business will notice IT being more in tune with their changing demands.

That said, IT will need to align its API strategy with the microservices that developers produce. Securing those microservices should be of the utmost importance – and leveraging API Gateways in this context is the right choice.  Always remember that if you’re looking for speed and scale, safety is equally important.  And a strong API management component is a must.