Google offers advice about microservices and refactoring apps

Pioneered by Netflix, microservices have quickly become one of the biggest trends in app development, giving developers greater flexibility and agility when it comes to building modern apps.

While these new architectures can offer vast improvements over more traditional monolithic deployments, it’s essential developers understand when and where these technologies are best suited, and how they fit into the broader development lifecycle.

We spoke with Tim Hockin, principal software engineer at Google Cloud, to understand how the company views microservices, their advantages and disadvantages over alternative development approaches, and why microservices are particularly well suited for the cloud.

ADM: How does Google Cloud define microservices?

Hockin: There's not a "true" definition of either "service" or "microservice". A "service" generally refers to a network-oriented, API-driven program that performs some actions on behalf of the caller, and is composed into larger applications. A "microservice" is generally understood to be a service with a very limited set of responsibilities. By way of example, a microservice's sole responsibility might be to authenticate users or to look up user contact info.

In truth, microservices have existed as long as we have had subroutines in programming languages. Microservices are really just a bunch of smaller applications, each with an individual API that can be used by the others.

ADM: What’s the difference between a monolithic architecture and a microservices architecture?

Hockin: A monolithic app is a single large application which does everything itself, often literally in a single binary. Development can be done by multiple teams, but at the end of the process, the whole application is versioned, tested, and deployed as a single unit. When a developer needs to scale their application, they have to manage each subsystem at the same time, and when it crashes, the whole thing goes down.

A microservice-based app is built from multiple smaller applications communicating via well-defined APIs. Development can be done by multiple teams, which produce multiple binaries. The application can be managed as a whole, or more likely, each service can be managed independently. The auth team can develop, build, test and deploy the auth service completely independently from the frontend or database. If a team needs more frontend performance, they can optimize and scale just the frontend, without worrying about the database. If the frontend crashes, the database is not impacted.

ADM: What are the key benefits of developing on a microservices architecture?

Hockin: Microservices offer a lot of flexibility and power. A developer can choose different frameworks or even different languages for each part of their larger application. Teams that are focused on their own subsystems don't have to worry about what other teams are doing, and can manage their service as its own independent entity. While teams will still need to do end-to-end integration testing, the develop-build-test-repeat cycle can be faster and more localized, and the "blast radius" of any one bug is limited.

ADM: Why are microservices architectures well suited for the cloud?

Hockin: Cloud is all about elastic capacity and decoupling. Elastic capacity means developers can rapidly scale up and down as needed. Decoupling means that applications are less tightly bound to physical hardware or environments. APIs are the norm. This fits well with microservices and the mindset around them. As before, if a developer needs more frontend performance, they can simply add more frontend replicas, and the elastic nature of cloud means that they don't have to pre-provision hardware to handle it. It’s there, on demand.

ADM: What is domain driven design and how does it apply to microservices?

Hockin: Domain driven design (DDD) is a way of thinking about software design that focuses on expertise in the problem space (the domain) and seeks to establish common language and methodology around that domain. Like so many software development philosophies, the details that set DDD apart from another concept such as object-oriented programming are subtle. DDD has a natural service-oriented mindset, which can map well to microservices.

ADM: What are the key considerations for developers looking to refactor applications for microservices?

Hockin: Developers should first know WHY they are doing it. Don't do it unless the development team can clearly express the value they seek to achieve. That could be anything from improving developer velocity to centralizing shared services to more isolated testing.

It’s also essential developers know their problem domain well. Many attempts at microservices flop because people didn't properly understand the natural "seams" of their application and factored out the wrong microservice API.

Be ready to take things like API compatibility, version skew, and SLAs very seriously. These are critical aspects of microservice architectures.

Finally, be aware that there are no magic bullets. Microservices have costs. Logging, monitoring, debugging and operations are all things that can get more complicated when an app moves from being a monolith to a distributed system.

ADM: What trends do you see shaping how developers approach microservices over the next year?

Hockin: I think developers mostly understand WHY they want to embrace microservices. What they struggle with is how to achieve them. They have applications that are business-critical, that they can't simply turn off or rewrite. I hope we see more tools and systems designed to help developers who aren't starting from scratch adopt microservices. They need to address a range of issues, such as lifecycle management, monitoring and visibility, and authentication and security policy enforcement.

As microservices become more popular, I expect we'll see new languages or language constructs that make writing microservices faster and easier. We'll see more emphasis than ever on APIs and API management. We'll also see demand for ways to transparently integrate "legacy" apps with microservice apps.

Developers will still be focused on delivering value to their businesses. Microservices will only succeed when they make that easier.

About Tim Hockin

Tim is a principal software engineer at Google, where he works on the Kubernetes and Google Container Engine (GKE). He is a co-founder of the Kubernetes project, and he is responsible for topics like networking, storage, node, multi-cluster, resource isolation, and cluster sharing. Before Kubernetes, he worked on Google's Borg and Omega projects as well as the Linux Kernel, and before that he enjoyed playing at the boundary between hardware and software in Google's production fleet.