Following the online webinar Exploring the Uncharted Territory of Microservices organized by XebiaLabs, which we covered in The Benefits of Microservices, Randy Shoup, Consulting CTO at Randy Shoup Consulting and former Director of Engineering for Cloud Computing at Google and Andrew Phillips, VP Product Management at XebiaLabs, answered a number of questions on microservices asked by participants. We have compiled and edited excerpts from those answers. The complete answers are here (PDF).
How does a microservices architecture compare with a n-tier one?
Shoup considers that a microservices architecture is more of an “ecosystem of cooperating independent services than a strict tiered model”, with each microservice implementing “one functional area and one area only.” He also sees sharing direct data access between multiple microservices as an anti-pattern.
Phillips added that while a microservice serves one business need, there can be multiple tiers within a microservice such as a “persistence component, a web component, a business logic/service layer, etc.”
How can one ensure data integrity when a service call fails?
Shoup emphasizes the importance of having only one “single (logical) system that is the system of record for any piece of data”, but the data may be cached in different places throughout the system. It is necessary to have a “guaranteed event system” that informs all participants when there is a change in the original data, so they would not operate with invalid information. When a complex transaction involves multiple microservices, the guaranteed event system would ensure that the respective “business activity ultimately completes successfully.”
Phillips suggests a different approach, making the “most user-facing component” of the system responsible for updating the data throughout the system when a change occurs by issuing multiple calls to each microservice interested in having a copy of the respective data. He acknowledges that this approach makes the user-facing component more complicated but, in the same time, by having the responsibility for propagating a data change in one place makes it easier to decide what to do when a service call fails.
Is it possible to end up with an incomplete customer order when using microservices?
If multiple microservices are involved in creating an order, Shoup proposes to maintain a “state machine on that order with various intermediate states.” But he adds that it is simpler to have an Order microservice that takes care of everything related to orders. It may create the order itself, or it can orchestrate calls to other microservices involved in this operation.
Phillips considers that when multiple microservices are involved in processing an order, the order microservice should listen to order-related events and update the state for the respective order when an operation is executed against it.
Are microservices an architectural style or a SOA implementation strategy?
Shoup thinks it can be both:
A Microservice approach has strong architectural implications, in that it keeps components small, and avoids shared persistence. At the same time, Microservices are SOA done properly — where each service is simple, composable, and self-contained. “Microservice” is a new name for the old concept of encapsulation.
Phillips mentions that “there are so many flavors of definitions for both microservices and SOA, that the answer could be pretty much anything.” Then he details that “both SOA and Microservices are architectural styles that emphasize independent services, but have quite a different focus on the types of service that need to be independent: SOA is focused on independent technical systems, Microservices focuses on independent business systems.”
How can one manage the graph of dependencies between microservices?
Shoup considers that it is not necessary to “view the entire ecosystem globally” but only the “in- and out- dependencies” of each microservice. What is necessary is to “standardize on protocols, formats, security characteristics, etc.”. A monitoring system could be used to understand what is happening at runtime, and to quantify the ripples generated by a change in a microservice one needs to consider its clients.
Phillips thinks that “any real-world microservice architecture is generally too complex to understand globally”, and one should instead try to understand local dependencies. This can be done at runtime with monitoring tools, “especially message tracking tools in environments that use event propagation as an asynchronous communication mechanism between services.” He points to Netflix’s approach as an example.
Also, Phillips notes that a microservice’s “local environment” needs to be consistent when attempting to test or deploy it, without having a tool overseeing the entire system of dozens or hundreds of microservices:
if you’re about to push service A into an environment and you know service A needs to communicate with two APIs of particular versions (you could also say “with two other services”, but in general it makes more sense to talk about APIs that are provided or consumed), then it makes sense to a) be able to describe that dependency b) to have tooling that can validate that dependency or, better still, c) automatically ensure that dependency will be fulfilled by e.g. deploying the versions of those services exposing the required APIs to your target environment alongside your app.
How to send bulk data from a microservice to a data warehouse?
Even if it is about large amounts of data needed to be transferred, Shoup still believes that one should not “go behind the published interface and read or write in the Microservice’s persistent storage,” but to go through the supported interface. A more efficient transfer protocol might be used, but still accessing the microservice’s published API.
Phillips agrees with Shoup, mentioning Amazon Glacier as example, “a type of storage API for very cheap bulk storage” which offers “asynchronous API calls that may take up to 24h to complete, because at the backend a robot needs to retrieve tapes from storage.”
Why should changes be done in small steps?
Shoup sees Microservices, Continuous Delivery, Agile practices, and DevOps as complementary approaches for delivering great software. When implementing microservices, “individual changes are bounded and easily understood, so it is easier to adopt a process of continuous integration or continuous delivery,” breaking down a larger feature into “many small steps, each of which can be understood, implemented, tested, and deployed individually.”
Phillips considers that people are seeing some features as “big” because of the overhead needed to push them into production: “if it takes 25 people in a conference room a whole weekend to deploy something to production, you will not do it simply to change one line of code.” He supports the idea of having small features where changes are simple and pushing them to production is done automatically with tools without manual intervention.
How do you define microservice architecture?
Shoup: “A loosely-coupled service-oriented architecture with bounded contexts”.
Phillips: “a way of designing software applications as suites of independently deployable services,” quoting Martin Fowler’s definition.
What do you recommend for communication between microservices?
Shoup saw in production mostly synchronous communication based on HTTP/REST/JSON, and fewer asynchronous approaches.
Phillips argues that “there is no One Best Choice.” What is important is to “standardize on the protocols used as much as possible, as this makes management and monitoring of your overall landscape much easier. “
How does TDD work in a microservices architecture?
Shoup: “Microservices lend themselves very well to TFD / TDD, because the Microservice is a natural testing boundary, and is simple enough to be tested pretty completely. “
Phillips considers that microservices can be easily tested individually, but it is much more challenging to “figure out how to test entire user scenarios that rely on multiple microservices communicating with each other … because you need to coordinate more moving parts to get a test environment running in the first place.”
Would you recommend a governing structure? SLAs?
Shoup does not recommend a top-down control structure because it becomes a bottleneck in the whole development/deployment process, but rather to standardize on “a (supported) set of common libraries for building a microservice,“ suggesting Neflix OSS projects as a starting point. He is also a big fan of SLAs, making it clear what a client can expect from a microservice.
Phillips sees as “critical” to have a “contract” that goes beyond the published interface, specifying the expected performance parameters.
What is the difference between a web service and a microservice?
Shoup: “They are orthogonal concepts. A web service is a service exposed through a web protocol like HTTP. A microservice is a service that is small, simple, and composable. Many microservices are, in practice, web services. But only some web services are microservices.”
Phillips: “not every microservice has to be a web service. The choice of communication protocol for your microservices will depend on what they do.”
About the Interviewees
Randy Shoup is the Chief Technology Officer at KIXEYE, making awesome games scalabler and reliabler. Previously, he was Director of Engineering at Google, leading several teams building Google App Engine, the world’s largest Platform as a Service. Prior to Google, he spent 6 1/2 years as Chief Engineer at eBay, building several successive generations of eBay’s real-time search engine.
Andrew Phillips is VP Product Management at XebiaLabs. Andrew is an evangelist and thought leader in the DevOps, Cloud and Delivery Automation space. Andrew sits on the management team and drives product direction, positioning and planning. - See more here.