Several organizations have a migration to microservices planned as long term goal. But how will you know when it’s finally time to make the switch? You know it’s worth the investment, you’ve even got some of management on board, but it’s a huge undertaking and you haven’t yet broken ground. There are so many patches, feature upgrades and bugs to fix with your current platform – how can you spare developer time for such a lofty, ambiguous goal?
Microservices architecture is not a new term or software development framework (heck, Groupon made the switch half a decade ago!), but success stories of growth and scalability are only starting to pour in. This is because the migration process can take years for large platforms, and the fruits of your labor only become apparent after the platform grows. The main goal of switching to microservices is to foment a culture of continuous, automated deployment from self-service teams. When executed properly, this makes companies more agile in development, creative with deployment strategies and adaptive to changing product requirements.
If you’re on the fence with committing to microservices, here are a few key considerations to help you decide whether it’s time to clean the garage, call the cousins, or jump into the new paradigm.
Rapid Development and Deployment from Self-Service Teams
In contrast to monolithic architecture in which logic is layered and self-contained, microservices distribute business processes across modular components that communicate over a lightweight messaging system. This means that services can be developed and deployed (not to mention managed) independently, as long as the role of each service is clearly defined and communicated via strong contracts. When thoughtfully designed, each service is narrow in scope and reflects a specific business process of your company.
For example, an ecommerce application might have a product listing service, an images service, and a pricing service that are all called upon on the same page. These services can be written in different languages, use different databases, and even spread compute across a variety of resources (plenty of opportunities for cost saving). Google Cloud provides plenty of documentation on getting started in microservices, suggestions for how to structure certain types of applications, and how to efficiently distribute processes across the platform. Register for upcoming Google and SADA Systems webinar to learn more.
Setting Up a Dev Environment Conducive for Microservices
As you can already tell, there are certain scenarios where microservices will speed up your current deployment process but also a few use cases where they would actually make it more complex. In the perfect scenario, a simple feature update to the pricing service can be unceremoniously deployed by the developer in charge, as opposed to waiting on full redeployment of the entire application in the monolithic approach.
However, pipe dreams like this are only made possible when developers have an adequate environment for development, testing and deployment of the services they manage. Setting up a local development environment in a microservices application can be surprisingly complex: how much of the dev environment should run locally, and how much should be in cloud? If we choose to run development services remotely in the cloud, what is the impact on cost and speed? Google provides guides for setting up microservices and Kubernetes locally for development. Every development environment may look different, but the main goal is to be consistent and structured in order to avoid deployment headaches (the main reason we’re doing microservices in the first place!).
Canary Deployments, Failover and Rollback
A properly designed microservices application shouldn’t just make deployment smoother, it should also make it more creative and transparent. In both Google App Engine and Google Container Engine, services can be deployed as A/B tests to collect user data. This allows a development team to be more open to new feature rollout to small, specific user populations. Different logs can be created across service versions, and cost tracking can also be split up across service versions. By the same token, it’s much easier to roll back a service when a bug is pushed to production without having to scramble to fix and redeploy the whole application.
With Kubernetes, services can run on multiple instances that can be defined via YAML files. This helps your app scale on demand, but it also allows a new instance to be created in the event that one becomes unhealthy. Monitoring through Kubernetes also makes it easier to detect a service that fails. And don’t worry – a failing node won’t take down the entire service in a microservices application. Instead, Kubernetes simply spins up a new node to protect you against machine failure.
Overall, deployment can be a more fluid, accelerated process that also gives you a bit of breathing room in the event of a mistake. It’s also worth noting that a microservices environment running on Kubernetes allows your code to run across cloud environments. So, if you prefer certain services to run on different platforms, or if you simply wish to avoid vendor lock-in, you can configure your Kubernetes deployments across clouds with very little additional work.
Before Making the Switch: Consider Your Business Needs
Microservices platforms are perfect for companies with development teams of any size, applications with plans to scale, and applications that already have an enormous amount of tech debt.
On the other hand, if your application feels like a tower waiting to topple, in which development domain expertise is spread thin across your entire code repository, the delicate balance has an expiration date. It’s time to get management on board for investment in a scalable, flexible future that saves development time (ahem, money) in the long run.
To learn more, register for an upcoming Google and SADA co-hosted webinar outlining the steps and expected results.
Simon Margolis
Director | Cloud Platform
