Book: Microservice Architecture

Posted on by Dave
microservices_arch“Microservice Architecture: Aligning principles, practices, and culture” by Irakli Nadareishvili, Ronnie Mitra,
Matt McLarty & Mike Amundsen
  • “What the architects at this gathering were concerned with was not a question of the size of the system. Instead, they were
    grappling with a situation in which the system was too big. What they identified is that systems that grow in size beyond the boundaries we initially define pose particular problems when it comes to changing them. In other words, new prob‐
    lems arise due to their scale.”
  • “Microservice architecture isn’t about identifying a specific collection of practices, rather it’s an acknowledgment that software pro‐fessionals are trying to solve a similar goal using a particular approach. There may be a set of common characteristics that arise from this style of software development, but the focus is meant to be on solving the initial problem of sys‐tems that are too big.”
  • “The revelation that microservices are really about replaceability is the most enlightening aspect of the story. This idea that driving toward replacement of components rather than maintaining existing components get to the very heart of
    what makes the microservices approach special.”
  • “A microservice is an independently deployable component of bounded scope that supports interoperability through message-based communication. Microservice architecture is a style of engineering highly automated, evolvable software systems made up of capability-aligned microservices.”
  • Characteristics of microservices applications
    • “Small in size”
    • “Messaging enabled”
    • “Bounded by contexts”
    • “Autonomously developed”
    • “Independently deployable”
    • “Decentralized”
    • “Built and released with automated processes”
  • “Decentralization means that the bulk of the work done within your system will no longer be managed and controlled by a central body. Embracing team autonomy means trusting your development teams to make their own decisions about the software they produce. The key benefit to both of these approaches is that software changes become both easier and faster—less centralization results in fewer bottlenecks and less resistance to change, while more autonomy
    means decisions can be made much quicker.”
  • “In a microservice architecture, the services tend to get simpler, but the architecture tends to get more complex.
    That complexity is often managed with tooling, automation, and process.”
  • “But microservices can’t be achieved by focusing on a particular set ofpatterns, process, or tools. Instead, you’ll need to stay focused on the goal itself—asystem that can make change easier.”
  • “More specifically, the real value of microservices is realized when we focus on two key aspects—speed and safety. Every single decision you make about your software development ends up as a trade-off that impacts these two ideals. Finding an effective balance between them at scale is what we call the microservices way.”
  • “In fact, most teams are happy if they can manage a release in a week. Why is that? The answer of course is that the real deterrent to release speed is the fragility of the software they’ve produced.”
  • Beneifts
    • “Lessens dependencies between teams, resulting in faster code to production”
    • “Allows lots of initiatives to run in parallel”
    • “Supports multiple technologies/languages/frameworks”
    • “Enables graceful degradation of service”
    • “Promotes ease of innovation through disposable code—it is easy to fail and move on”
    • “Some services require high availability, but are low volume, and it’s the opposite for other services. A microservice approach allows us to tune for both of these situations, whereas in a monolith it’s all or nothing.”
  • Speed focused business value
    • “Agility allows organizations to deliver new products, functions, and features more quickly and pivot more easily if needed.”
    • “Composability reduces development time and provides a compound benefit through reusability over time.”
    • “Comprehensibility of the software system simplifies development planning, increases accuracy, and allows new resources to come up to speed more quickly.”
    • “Independent deployability of components gets new features into production more quickly and provides more flexible options for piloting and prototyping.”
    • “Organizational alignment of services to teams reduces ramp-up time and encourages teams to build more complex products and features iteratively.”
    • “Polyglotism permits the use of the right tools for the right task, thus accelerating technology introduction and increasing solution options.”
  • Safty focused business value
    • “Greater efficiency in the software system reduces infrastructure costs and reduces the risk of capacity-related service outages.”
    • “Independent manageability contributes to improved efficiency, and also reduces the need for scheduled downtime.”
    • “Replaceability of components reduces the technical debt that can lead to aging, unreliable environments.”
    • “Stronger resilience and higher availability ensure a good customer experience.”
    • “Better runtime scalability allows the software system to grow or shrink with the business.”
    • “Improved testability allows the business to mitigate implementation risks.”
  • “Although a single service may be understandable even in a modularized microservice architecture, the overall software system is only comprehensible when the connectivity between services is known. Also, agility is only possible when the
    impacts of changes on the whole system can be identified and assessed rapidly.”
  • “Lastly, although individual components may be isolated and made resilient in a modularizedor cohesive microservice architecture, the system availability is not assured unless the interdependencies of the components are understood.”
  • “Designing for an ideal or average is likely to result in a model that fits no single purpose well. Guidance that calls out specific measurements of an ideal microservice or canonical model for microservices is likely to have traits that fit no
    existing microservice implementation. Ideals are just that—not realities.”
  • “When designing a particular microservice your decisions are bounded by the need to produce a single output—the
    service itself. Conversely, when designing a solution architecture your decisions are bounded by the need to coordinate all the inputs and outputs of multiple services. This macro-level view of the system allows the designer to induce more desirable system behavior. For example, a solution architecture that provides discovery, safety, and routing features can reduce the complexity of individual services.”
  • “Choosing the right processes and tools is an important factor in producing good microservice system behavior. For example, adopting standardized processes like DevOps and Agile or tools like Docker containers can increase the changeability of your system.”
  • “We can broadly define culture as a set of values, beliefs, or ideals that are shared by all of the workers within an organization. Your organization’s culture is important because it shapes all of the atomic decisions that
    people within the system will make.”
  • “Standardization is the enemy of adaptability and if you standardize too many parts of your system you risk creating
    something that is costly and difficult to change.”
  • “By standardizing the way that people work and the tools they use, you can influence the behavior in a more predictable way. For example, standardizing a deployment process that reduces the time for component deployment may improve the overall changeability of the system as the cost of new deployments decreases.”
  • “But we may find that constraining the types of APIs our people are allowed to produce limits the types of tools they can use to create them. It might be the case that the development tool we want everyone to use doesn’t support the interface description language we have already chosen. In other words, the decision to standardize the team’s output has had unintended consequences on the team’s work process. This happens because standardization is an attempt to remove uncertainty from our system, but comes at the cost of reducing innovation and changeability.”
  • “The behavior of your microservice system is “correct” when it helps you achieve your goals.”
  • “But as you go through the system design process you will find that it is difficult to pull your system into many directions at the same time. A smaller set of optimization goals is easier to design for.”
  • “For example, a financial information system might be optimized for reliability and security above all other factors. That doesn’t mean that changeability, usability, and other system qualities are unimportant—it simply means that the designers will always make decisions that favor security and reliability above all other things.”
  • “Underpinning a system optimization goal is a set of principles. Principles outline the general policies, constraints, and ideals that should be applied universally to the actors within the system to guide decision-making and behavior. The best designed
    principles are simply stated, easy to understand, and have a profound impact on the system they act upon.”
  • “Gathering information about your system by identifying KPIs is useful, but being able to utilize those metrics to predict future behavior is incredibly valuable.”
  • “So, in order to design a microservice system that is dynamic you’ll need to identify the right KPIs, be able to interpret the data, and make small, cheap changes to the system that can guide you back on the right course. This is only possible if the right organization, culture, processes, and system architecture are in place to make it cheap and easy to do so.”
  • “Here are the four goals toconsider:
    1. Reduce Cost: Will this reduce overall cost of designing, implementing, and maintaining IT services?
    2. Increase Release Speed: Will this increase the speed at which my team can get from idea to deployment of services?
    3. Improve Resilience: Will this improve the resilience of our service network?
    4. Enable Visibility: Does this help me better see what is going on in my service network?”
  • “For microservices, this means coming up with ways to reduce the cost of coding and connecting services together. Templated component stubs, standardized data-passing formats, and universal interfaces are all examples of reducing the costs of coding and connecting service components.”
  • “By automating important elements of the deployment cycle, you can speed up the whole process of getting services into production.”
  • “Unlike goals, which are general, principles offer more concrete guidance on how to act in order to achieve those goals. Principles are not rules—they don’t set out required elements. Instead, they offer examples on how to act in identifiable situations. Principles can also be used to inform best practices.”
  • Example Principles from Netflix
    • Antifragility: “The point of antifragility is that you always want a bit of stress in your system to make it stronger.”
    • Immutability: “Cockcroft says the principle of immutability is used at Netflix to assert that autoscaled groups of service instances are stateless and identical, which enables Netflix’s system to ‘scale horizontally.'”
    • Separation of Concerns: “Each team owns a group of services. They own building, operating, and evolving those services, and present a stable agreed interface and service level agreement to the consumers of those services.
      Invoking Conway’s law, an organization structured with independent selfcontained cells of engineers will naturally build what is now called a microservice architecture.”
  • Suggested principles
    • Do one thing well: “For some, ‘one thing’ is managing user accounts. For others, ‘one thing’ is finding a single user record.”
    • Build afresh: “It may be better to build a new microservice component rather than attempt to take an existing compo‐
      nent already in production and change it to do additional work.”
    • Expect output to become input: “On the Web, the data-passing medium is the media type (HTML, HAL, Siren, Collection+JSON, etc.). In some cases, you can even use HTTP’s content-negotiation feature to allow API providers and consumers to decide for themselves at runtime which format will be usedto pass data.”
    • Don’t insist on interactive input: “Human interaction isn’t something that microservice components need to deal
      with at runtime. But when we expand our scope of focus to the microservice system, it’s easy to find countless human interactions that could benefit from this principle. Reducing the dependency on human interaction in the software development process can go a long way toward increasing the speed at which change occurs.”
    • Try early: “Adopting the point of view that your microservice components should be ‘tried
      early’ fits well with the notion of continuous delivery and the desire to have speed as a goal for your implementations. Another advantage of this ‘try early’ principle is you will learn your mistakes early. It turns out ‘try early’ is also a way
      to encourage teams to get in the habit of releasing early and often. The earlier you release (even when that release is to a test environment), the earlier you get feedback and the quicker you can improve.”
    • Don’t hesitate to throw it away: “However, when you adopt the ‘try early’ principle, throwing away
      the early attempts is easier.”, “Over time, components that did an important job may no longer be needed. You may have applied the ‘build afresh’ principle and replaced this component with one that does the job better.”
    • Toolmaking: “The important element here is to recognize that, in some cases, you may need to divert from building your solution and spend some time building tools to help you build that solution.”
  • See post mortem tracker: https://github.com/etsy/morgue
  • “One of the primary goals of the local capabilities set is to help teams become more self-sufficient. This allows them to work at their own pace and reduces the number of blocking factors a team will encounter while they work to accomplish their
    goals. Also, it is common to allow teams to make their own determination on which developer tools, frameworks, support libraries, config utilities, etc., are best for their assigned job. Sometimes these tools are selected from a curated set of ‘approved’ products. Sometimes these tools are created in-house (even by the same team).”
  • “A key local capability is the power to automate the process of rolling out, monitoring, and managing VMs and deployment packages. Netflix created Asgard and Aminator for this.”
  • “Twitter’s Decider configuration tool is used by a number of companies for this including Pinterest, Gilt, and Twitter. This tool lets teams use configuration files to route traffic from the ‘current’ set of services to the ‘newly deployed’ set of services in a controlled way.”
  • “Facebook created their own tool called Gatekeeper that does the same thing. Again, placing this power in the hands of the team that wrote and released the code is an important local capability.”
  • “There are a handful of popular service discovery tools including Apache Zookeeper, CoreOS’ etcd, and HashiCorp’s Consul.”
  • “These tools make it possible to build and release services that, upon install, register themselves with a central source, and then allow other services to “discover” the exact address/location of each other at runtime. This ability to abstract the exact location of services allows various teams to make changes to the location of their own service deployments without fear of breaking some other team’s existing running code.”
  • “However, as service requests scale up, it is common to “front” the web servers with specialized routing proxies or gateways. Netflix created Zuul to handle their routing. There are popular open source services like Netty (created by JBoss) and
    Twitter’s Finagle.”
  • “Twitter created (and open sourced) Zipkin for this task, and there are other similar frameworks that provide visibility into the state of the running system.”
  • “Netflix’s Hystrix is one of those tools. It implements a pattern known as the Circuit Breaker to improve the resiliency of running systems.”
  • “Culture is important because it not only sets the tone for the way people behave inside an organization, but it also affects the output of the group. The code your team produces is the result of the culture.”
  • Aspects of culture that impact performance
    • Communication: “Research shows that the way your teams communicate (both to each other and to
      other teams) has a direct measurable effect on the quality of your software.”

      • “Organizations which design systems … are constrained to produce designs that are
        copies of the communication structures of these organizations.”
        —Mel Conway, author of “How Do Committees Invent?”
    • Team alignment: “The size of your teams also has an effect on output. More people on the team
      means essentially more overhead.”
    • Fostering innovation: “Innovation can be disruptive to an organization but it is essential to growth and
      long-term success.”

      • “It’s worth noting that being innovative is most often focused on changing something that is already established. This is different than creating something new. Innovation is usually thought of as an opportunity to improve what a team or company already has or is currently doing.”
      • “Companies we talked to enable innovation by adopting a few key principles. First, they provide a level of autonomy to their teams. They allow teams to determine the best way to handle details within the team.”
      • “Second, companies that foster innovation build in a tolerance for some level of chaos. They operate with the understanding that it’s OK if some things look a bit disorganized or messy. Of course, there are limits to this. Harvard Business Review’s ‘Managing Innovation: Controlled Chaos’ points out that ‘Effective managers of innovation… administer primarily by setting goals, selecting key people, and establishing a few critical limits and decision points for intervention.’ Fostering innvotation means setting boundaries that prevent teams from taking actions that threaten the health and welfare of the company and allowing teams to act on their own within these safe boundaries.”
  • “In the spirit of empowerment and delivery speed, Hootsuite does not have any governance checkpoints that intrude on a team’s development process. Instead, they have a set of community-defined principles and tools that guide microservice
    development.”
  • “If our service boundaries align to the bounded contexts in our domain, and our micro‐services represent those bounded contexts, we are off to an excellent start in ensuring that our microservices are loosely coupled and strongly cohesive.”
  • hypermedia API: “This is an API style in which API messages contain both data and controls (e.g., metadata, links, forms), thus dynamically guiding API clients by responding with not just static data but also control metadata describing API affordances (i.e., ‘what can I do with this API?’).”
  • “Hypermedia APIs are more like the human Web: evolvable, adaptable, versioning-free—when was the last time you cared about what “version” of a website you are looking at? As such, hypermedia-style APIs are less brittle, more discoverable, and fit right at home in a highly distributed, collaborative architectural style such as microservices.”
  • “Thinking in terms of capabilities rather than data is a very powerful technique for API design, in general. It usually results in a more use-case-oriented interface (instead of an SQL-like data-object interface). A capabilities-centric API design is usually a good approach, but in the case of microservices it is not just a smart design technique, it’s a powerful way of avoiding tight coupling.”
  • “Event sourcing is all about storing facts and any time you have ‘state’ (structural mod‐
    els)—they are first-level derivative off of your facts. And they are transient.”
    —Greg Young, Code on the Beach, 2014
  • “Fortunately, in event sourcing, we can avoid such expensive operations by using a so-called rolling snapshot—a projection of the entity state at a given point in time. Depending on the event source implementation, it is common to snapshot intermediary values at various time points. For instance, you may precalculate your bank account balance on the last day of every month, so that if you need the balance on January 15, 2016 you will already have it on December 31, 2015 and will just need to calculate the projection for two weeks, instead of the entire life of the bank account.”
  • “Command query responsibility segregation is a design pattern that states that we can (and sometimes should) separate data-update versus data-querying capabilities into separate models. It tracks its ancestry back to a principle called command–query separation (CQS), which was introduced by Bertrand Meyer in his book Object-Oriented Software Construction (Prentice-Hall, 1997). Meyer argued that data-altering operations should be in different methods, separated from methods performing read-only operations. CQRS takes this concept a large step further, instructing us to use entirely
    different models for updates versus queries.”
  • “Sagas are very powerful because they allow running transaction-like, reversible work‐flows in distributed, loosely coupled environments without making any assumptions on the reliability of each component of the complex system or the overall system itself. The compromise here is that Sagas cannot always be rolled back to the exact initial state of the system before the transaction attempt. But we can make a best effort to bring the system to a state that is consistent with the initial state through compensation.”
  • “Generally speaking, teams adopting a microservice architecture are expected to have a certain level of infrastructure automation and operational maturity to be successful.”
  • “A capable API gateway will allow you to declaratively, through configuration, create API interfaces that can orchestrate backend microservices and “hide” their granularity behind a much more developer-friendly interface and eliminate chattiness. In our example scenario, we can quickly aggregate the N+1 calls into a single API call and optimize the response
    payload. This gives mobile developers exactly what they need: a list of recommendations via a single query, with exactly the metadata they required. The calls to backend microservices will be made by the API gateway. Good API gateways can also
    parallelize the twenty calls to the Product Metadata microservice, making the aggregate call very fast and efficient.”
  • “The ideal organization for microservices has small, empowered teams responsible for services that align with specific business domains. These teams feature all of the roles necessary to deliver these services, such as product owners, architects, developers, quality engineers, and operational engineers. The teams also need the right skills, such as API design and development, and knowledge of distributed applications.”
  • “…the challenge is to find small changes that can unfold in a way that creates large
    effects…”
    —Gareth Morgan, author of Images of Organization
  • “SoundCloud’s Phil Calçado has written about using a lean management technique called value stream mapping as an initial step toward microservices.”
  • “No matter how you do it, the goal in this step is to identify how software changes are introduced to the system, who implements those changes, and the type of coordination that is required for those changes to take place.”
  • “In particular, you should be looking for the bottlenecks that cause change to be expensive.”
  • “Finding these bottlenecks will help you identify good candidates for process and organizational refactoring as they should yield a large benefit to the changeability and speed of release for the system.”
  • “A hallmark of a microservices organization is that the teams that implement a feature, application, or service continue to support, improve, and work on the code for its lifetime.”
  • “Typical project-centric cultures operate differently. Teams are formed to address a particular problem (e.g., create a new component, add a feature, etc.) and disbanded when that problem is solved. Often a good deal of knowledge about both the problem and the solution gets lost when the team disbands.”
  • “In truth, it is quite difficult to adopt the microservice style if you need to operate in this type of culture. If changeability and speed of release are important properties for your system, the long-term goal should be to transition to a style of building that encourages team-based ownership of components.”
  • “Ultimately, the selection process for a microservices outsourcing model cannot be optimized purely for low-cost work. You will need to carefully select a partner who is amenable to the cultural traits you are looking for and possesses aspects of culture you’d like to incorporate into your own system.”
  • See also:
Advertisement

Leave a Reply

Please log in using one of these methods to post your comment:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s