Published May 29, 2018

Abstract

This report is a level-set for enterprises considering microservices or alternative approaches to traditional application development and deployment. There have been a multitude of efforts over the years to build better software and services faster and less expensively. The microservices trend has gained increased visibility of late as organizations such as Google, Amazon, Netflix and others have rapidly deployed services at massive scale leveraging agile development teams to build small, loosely coupled services.

Enterprises are evaluating and embracing an overarching movement from traditional monolithic applications to smaller, autonomous services that work together under the umbrella of a microservice-based architecture. This allows for small, independent teams to develop business-focused services without waiting for all other services to be completed.  The goal is for this approach to result in efficient development, more consistent and frequent updates and greater flexibility.

At TechVision, we see microservices as enabling three specific, highly sought-after capabilities within the enterprise space: Faster Ideation-to-Realization, Lower TCO via Service Reuse, and Lower Operational Risk. With these three outcomes exists a re-balancing of assumptions at an engineering, financial and organizational level that, when effective, can lead to more integrative and even ‘DevOps’-like practices within the organization. We will continue to evaluate these dimensions as we dive deeper into the ‘what’ and ‘how’ of this architectural pattern throughout this report.

Authors:

Gary Rowe Principal Consulting Analyst/CEO [email protected]

Patrick McClory Principal Consulting Analyst [email protected]

Contributions From:

Gary Zimmerman Principal Consulting Analyst/CMO [email protected]

Chris Haddad Principal Consulting Analyst [email protected]

Executive Summary

This report focuses on providing IT executives, enterprise architects, developers and innovators with a “level set” as to what a microservice architecture is, its applicability in large enterprises, the current and expected future state of microservices and guidelines for deciding if, how and when your organization might embark upon this architectural pattern.

Microservices are components that can be thought of as independently replaceable and upgradeable building blocks. These components are independently built and managed and are assembled to create more complex applications as required by the business. That means a change to one component doesn’t require the entire system to be redeployed, as is the case with monolithic applications. Microservices decompose applications according a concept of single responsibility in which each microservice is activated via an API and executes discrete business capabilities (e.g. product catalogue, customer profile, reservation, inventory, order, billing, fulfillment) within a specific and well-defined context.

The goal of the microservice pattern is to deliver small, domain-bounded, and independent services.  If built correctly, microservice components fit hand-in-glove with the practices of agile programming, continuous integration, and especially continuous (automated) delivery.

Goals associated with microservices are accelerating pace and throughput; all valuable in supporting enterprise digital transformation initiatives. Most modern development organizations are looking for these types of capabilities. Pace starts with faster and more frequent iterations and faster deployment is a key design goal of microservices.  Throughput is improved by providing a means of separating tasks and independently designing, scaling and deploying services. This is achieved via automation and increased reuse of easy-to-access components and services.

By separating concerns onto discrete platforms and not sharing database instances or web application hosts across services, every team can choose different runtime languages and frameworks for its own microservice. Also, every team is free to evolve its data schemas, application frameworks, and business logic without impacting other teams. This empowers each team to be a “self-contained unit” and fully accountable for the results.

While TechVision sees substantial benefits and momentum behind microservices for the enterprise, it’s not for everyone or everything today. Most large enterprises have not yet moved to microservices and have monolithic and other applications that will not (and in many cases should not) go away for the foreseeable future. While we are very “bullish” about the future of microservices in the enterprise, tread carefully and incrementally when moving your enterprise in this direction.

Once the decision has been made to move to a microservices pattern, the following best practices are described the help organizations succeed with their early deployments:

• Manage microservices and APIs as “business products” from conception to retirement
• Control service access based on business requirements, not technical constraints
• Design for service unavailability (failure)
• Manage SLAs
• Support service discovery and definition
• Architect an appropriate level of microservices granularity
• Consistent data management

We conclude the report with a set of practical steps organizations can take to build out a microservices program.

Introduction

This report is part of a series of reports from TechVision Research covering trends in modern software development and operations management practices. As it becomes easier for technologists and even business users to gain access to a greater variety and depth of capabilities ‘with a laptop and a credit card,’ we see a number of technical patterns and practices exerting their influence in this process in a historically disproportionate manner.

Microservices architectures, from a software development perspective, are transforming the creation of enterprise applications. This evolving design pattern leverages familiar tools and capabilities from object-oriented programming techniques to high-scale automation to re-balance the set of concerns a given set of applications must consider at a feature, function and operational level. Unique to this pattern is an approach to deploy small, stateless components and services in as granular a manner as possible so as to improve service level agreement (SLA) achievement as well as to reduce the peripheral risk of future updates by scoping the impact of those updates to these small boundaries of concern. In practice, this has the effect of reinforcing an automation-first approach out of necessity and, therefore, has the potential to reduce overall cost of management, improve system availability and, most importantly, can significantly reduce the practical time required to go from ‘business idea’ to deployed software.

This report provides a balanced perspective for enterprise decision-makers on the good and the bad of a microservices architecture approach. This includes the current state of microservices and where we see it moving over the next few years.

Understanding that the current landscape in the application development and systems operations roles continues to evolve, we have, in certain areas, identified how other orthogonal capabilities, patterns and practices can serve as catalysts, accelerators or even as a distraction to the topic at hand.

Business Drivers for Microservice Adoption

Before we dive into the technical underpinnings of the microservices approach for enterprise software development, we’ll first identify the pain points and the business-level ‘give and take’ driving businesses to evaluate new patterns and practices. Realistically, most global companies, especially established enterprises, have a comfort level with their existing teams and processes for accomplishing their technical missions and any change (even for the better) represents a risk to the overall business systems established.

At TechVision, we see microservices as enabling three specific, highly sought-after capabilities within the enterprise space: Faster Ideation-to-Realization, Lower TCO via Service Reuse, and Lower Operational Risk. With these three outcomes exists a re-balancing of assumptions at an engineering, financial and organizational level that, when effective, can lead to more integrative and even ‘DevOps’-like practices within the organization. We will continue to evaluate these dimensions as we dive deeper into the ‘what’ and ‘how’ of this architectural pattern.

Catalyst to Strategic Business Drivers

Organizations need to be adapt and change at an increasingly rapid pace. This filters down to how we develop software and supporting services. The widely publicized concept of the API economy is an attempt to capture the need for rapid change leveraging standardized services that can be rapidly served up as needed.

Choosing to leverage a microservices architectural pattern can help to reinforce other key strategic technical efforts within. We have found that organizations continue to reinforce three specific, strategic efforts with a focus on the opportunity to accelerate business goals.  These three strategic goals are IT modernization, a foundation to support growth and expansion and, ultimately digital transformation.

Figure 1 – the API economy

As articulated in the context of the API Economy concept, a microservices architecture offers a means of delivering on the value that impacts people, process, and technology to accelerate time to market. To achieve this, there needs to be a shift in team organization, processes and practices like DevOps, as well as re-aligning architecture to fit the problems to be solved rather than just layering on new iterations of technology layers.

IT Modernization

Many IT departments face the issue that their organization has grown over time, building a complex dependency of operational, organizational and technological legacies. Yet, many elements of the organization are highly dependent on these legacies for day-to-day business operations.

The traditional core IT infrastructure is designed for the stability and resilience required to manage transaction and support systems and is hard to change. The long-standing IT priority has focused on high-quality data management and built-in security to keep core business services reliable for systems leveraging the consistency and reliability of a static data center. While it is hard to move from existing systems and processes, these legacy elements are regarded as barriers blocking the road to digital transformation; deemed ‘too risky’, or assumed to be unable to make the journey. This creates what many have termed a bi-modal view of IT capability; where legacy environments are segregated and managed differently than newer capabilities. But this also isolates (and possibly ignores) the information and knowledge that has been built up over the years and adds a lot of administrative overhead.

Progressive organizations are using API patterns and microservices architectures to connect fresh new applications with legacy data sources or introducing new middleware layers (API gateways) to broker connections into older systems. This can deliver tangible transformation while retaining valuable legacy components. At the same time, it allows the organization to decouple efforts to modernize the underlying core IT capabilities from new development efforts.

Digital Transformation

By exposing business capabilities through service APIs, you can get a better understanding of the full customer experience, gain insight into future opportunities, and take advantage of the rich data that is generated. But leveraging APIs are only part of the foundation towards digital transformation.

As organizations seek to better leverage digital capabilities to further all aspects of their business, using patterns such as the microservices architecture are a tangible way to drive business outcomes. Similar to the ‘togetherness’ approach that a DevOps approach embodies, leveraging microservices within a digital transformation program can both help to focus technical teams on tangible business outcomes more directly, but also serve as a means of achieving greater buy-in at a business when the technical approach is more directly mapped to solving historical pain points around scope creep and delivery delays.

Growth and Expansion

A business that’s not growing is dying through lost profits or complacent employees. The last big microservices business driver we’ll examine is Growth and Expansion. With a world population of over 7 billion people, there is practically no limit the size of the market to which you can sell your products. There might be customers with similar needs and the buying power within your borders or in the international market that you simply not have reached. Digital transformation has brought several opportunities to expand beyond a particular geographic region or segment. Taking advantage of these opportunities will require the ability to turn up new channels and to pump out new products quickly — to be able to innovate fast, evolve, and to reuse what you have built rapidly when needed. Microservices are tailor-made for this kind of environment, especially when combined with the flexibility of the cloud.

Intersection of Cloud and Microservices

The movement to microservices starts with the Cloud. The Cloud is one of the key catalysts to enabling the rapid and automated deployment iterations that makes the microservices pattern valuable. In asking the question of why we haven’t designed software like this in the past, the concept of Cloud is really where the answer starts; with the change in a fundamental assumption about computing resources. In the Cloud-era acquiring a server (or an instance) no longer requires weeks of procurement or even days of provisioning on the part of an IT team.  IT leaders and developer that want/need resources can now acquire them nearly immediately and, more importantly, can discard them easily at dramatically lower cost.  This has set the foundation for innovation, iteration, failing fast and moving even faster.

This shift in assumptions from a resource scarcity model to JIT resource availability has provided an environment supporting the microservices model we describe in this report. We’ll now further describe microservices and their potential enterprise impact.

What are Microservices?

A microservices architecture is a means of delivering software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, mechanism to serve a business goal. In practice, these intentionally decoupled components are then composed into systems via the APIs and interfaces that they expose. Rather than a few, large components that are highly complex, it seeks to distribute capabilities into fault-tolerant, highly available and relatively small pieces of software, hence the name ‘microservices.’

To better frame this analysis let’s start by considering what characteristics microservices have at a high-level. The following list of characteristics of a microservice architecture was first published by James Lewis and Martin Fowler in 2014 and is considered a seminal work on the subject. This should provide a foundation for our deeper analysis throughout this report.

• Services not libraries. A component is a unit of software that is independently replaceable and upgradeable, and a microservices architecture is based on services which are independent components who communicate with a mechanism such as a web service request, or remote procedure call. This is different than the common method used in monolithic architecture, component libraries of code included within the codebase.
• Organized around Business Capabilities. When looking to split a large application into parts, organizations often focus on technology layers, leading to UI teams, server-side logic teams, and database teams. The microservice approach to dividing up responsibility is different; splitting up teams focused on services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistent storage, and any external collaborations. Consequently, the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.
• Products not Projects. Most application development efforts that we see use a project model: where the aim is to deliver some piece of software which is then considered to be completed. On completion the software is handed over to a maintenance organization and the project team that built it is disbanded. Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon’s notion of “you build, you run it” where a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden.
• Smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible – they own their own domain logic and act more as filters in the classical Unix sense – receiving a request, applying logic as appropriate and producing a response. Rather than a point of central orchestration, event-driven systems tend to allow for individual services to define their reactions to complex processes rather than relying on complex protocols such as WS-Choreography or BPEL.
• Decentralized tools. Rather than being constrained by particular technology standards, microservice practitioners prefer selecting the technologies that best solve the problem.  This leads them to produce useful tools that other developers can use to solve similar problems to the ones they are facing. These tools are usually harvested from implementations and shared with a wider group, sometimes, but not exclusively using an internal open source model. Bottomline, standards are developed through consensus, not dictated.
• Decentralized data management. Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems – an approach called Polyglot Persistence.
• Deployment automation. Many of the products or systems being built with microservices are being built by teams with extensive experience of Continuous Delivery. Teams building software this way make extensive use of automation techniques including automated testing and deployment in order to drive visibility and consistency into their overall software development lifecycle (SDLC).
• Designed for failure. A consequence of using services as components, is that applications are distributed across a network and need to be designed so that they can tolerate the failure of other services. Any service call could fail due to unavailability of the supplier and the consumer has to respond to this as gracefully as possible.
• Evolutionary design. If you wait to launch until you completely understand and deliver everything a customer wants, the customer will have moved on. The notion is to release, probe, and learn from the market response to the product. Each iteration improves the product and evolves it to match customer preferences. A key characteristic of microservice architecture is developing components that can be tuned and revised independently from the rest of the application.

Microservices are components that can be thought of as independently replaceable and upgradeable building blocks. These components are independently built and managed and are assembled to create the more complex applications as required by the business. A key objective for microservices is that a change to one component doesn’t require the entire system to be redeployed, as is the case with monolithic applications. Early adopters of this pattern tend to find this specific outcome difficult, but a focus on automation beyond just deployment and operational processes can be the key to achieving truly decoupled component deployments.

The notion of microservices has its roots in Domain Driven Design which organizes software programs around business domain objects that have defined boundaries. For example, the relationship between a hotel chain and a guest is complex and can be modeled based on the various interactions such as:

• Guest and online reservation service
• Guest and front desk attendant
• Guest and concierge
• Guest and housekeeping
• Guest and loyalty program

Each of these interactions involves several business domains and trigger events between them. If the boundaries between the domains are not defined correctly, the programs supporting those domains can become less cohesive (for instance, loyalty program objects embedded in the other domains) and more coupled (changes in the loyalty program require changes in other domains).  This creates a microservice architecture that is brittle and no longer supports the goal of independence.

However, if organized properly, a microservices architecture becomes a suite of capabilities that can be used in multiple contexts and through many different lenses. This allows for organizations who achieve this model for their purposes the ability to quickly pivot, add ‘value add’ features and have even moderate to large-scale new product launches be more of an effort in re-composing existing resources and services than wholesale and painful rewrites of business-critical software. Given a catalog of available services, even things like the reduction of duplicative work becomes a natural behavior of the overall system rather than a forced discipline requiring regular and costly manual intervention.

Solving Old Problems in a New Way

As noted earlier in explaining the intersection of this topic with the concept of the public cloud, the microservices pattern is truly a reaction to a shift in underlying assumptions of the systems they operate in and around.

One key example of this shift in underlying assumptions is that of the implicit assumption of failure within the public cloud. Traditionally, in a well-deployed virtualized environment on VMWare’s solution, an organization would leverage a toolset called vMotion to allow virtual machines to live-migrate between hosts without downtime and (generally) without anyone otherwise noticing. Especially in the Amazon Web Services (AWS) Elastic Compute Cloud (EC2) offering, there’s no access to the underlying hosts, and Amazon’s CTO Werner Vogels has been quite adamant that ‘everything fails all the time.^[1]’ This shifts responsibility of recovery from an infrastructure-level tool that handles it at a low level to more of an operational concern that can be managed via automation, but has significant impact to deployment topology, especially for systems that might have high availability solutions but where the underlying VMWare capabilities were deemed to be sufficient to meet SLAs.

The paradigm shift in this example cannot be overstated. With the rebalancing of control and responsibility of key layers of the network and system at large, even base assumptions like static IP addresses aren’t necessarily safe without additional configuration in a given cloud deployment. This is neither a good or bad thing but opens up an incredible opportunity to design systems that make fewer assumptions of the infrastructure layer of systems which, in our view, tend to make for more robust and reliable deployments. This doesn’t single out microservices as the only pattern capable of achieving this in any given environment, but we have found it helpful to articulate these changes in assumptions in reinforcing that responsibilities shift in multiple directions (upward to the application layer, downward to the infrastructure, etc.), but that the needs of the system haven’t changed, the tactics to achieve them have.

We discuss the impact of this set of changes in underlying assumption when we discuss the microservices design mindset further in this document.

Microservices Goals and Digital Transformation

Digital transformation is on the radar of most large enterprises; the opportunity to digitally engage with clients, prospects, trading partners and employees requires a flexible, adaptive and scalable set of capabilities and microservices is a candidate for providing this type of foundation. But why microservices and why might an organization consider it now?

We’ll start with the goals associated with microservices; they are pace, throughput and infrastructure optimization; all valuable in supporting enterprise digital transformation initiatives. Most modern development organizations are looking for these types of capabilities and we’ll now describe each of these goals/design elements of microservices and the overall value proposition.

Pace starts with faster and more frequent iterations, and faster deployment is a key design goal of microservices.  This starts with simplifying development and deployment while minimizing external dependencies. It is also achieved by leveraging every opportunity to automate virtually anything that can be automated. Minimizing dependencies, providing developers with the right tools and quickly provisioning the right resources is key to driving faster development and deployment.

Throughput is improved via providing a means of separating tasks and independently designing, scaling and deploying services. This is achieved via automation and increased reuse of easy to access components and services. Being able to deliver code quickly is paramount to getting an edge on the market, and time to market is quickly becoming a driving force in the marketplace.

The infrastructure optimization goal is to provide a more resilient, available and scalable set of services required for digital transformation. Microservices can support these goals through the use of granular packaging and deployment techniques including the use of containers.

Microservices are built to scale naturally as more instances of needed components can be added without scaling the entire application. Furthermore, network boundaries provide places to add queues, circuit breakers and other means of both scaling services and mitigating major disasters.  More importantly, you also gain scalability in your development teams, as you can add more teams to work independently, something which is hard to accomplish in a monolithic environment.

Key transformative components include leveraging core microservices at scale and providing a platform for event driven interactions.  Microservices further supports digital transformation by leveraging an API-centric architecture and event sourcing.

Microservices, Monoliths and Other Architectures

The stereotypical discussion related to the adoption (or not) of a microservices architecture tends to compare microservices to monoliths. For the uninitiated, the term ‘monolith’ tends to describe any highly coupled piece of software that bundles many if not numerous functions into one single deployment package. As discussed earlier related to how cloud intersects with microservices, we briefly discussed that a change in the underlying assumptions of the deployment environment are really at the root of some of this change. Monoliths serve well in environments where resources are scarce, it is difficult to iterate quickly with multiple deployments and where the underlying assumption of hardware stability exists. TechVision Research does not see this as either a binary decision, nor one in which organizations might make different choices for different workloads and environments. That being said, we are excited about the opportunities this pattern presents and see benefit beyond a technical best practice in this pattern.

We begin our discussion of the differences between monolithic and microservice architectures with an example; in this case the reservation application, Hotels.com^[2]. In this application, the user enters basic search criteria about when and where they are travelling. The application returns a list of available rooms from which the potential guest can choose. When the guest chooses a property, the reservation process begins with this display.

Figure 2 – screen shot of the Hotels.com reservation application.

In a monolithic web application, we mainly would use a three-tier architecture for the reservation system consisting of a:

• Presentation layer
• Business layer
• Data access layer

Figure 3 – a monolithic implementation of the reservation application

In this model, a traditional web application client (a browser) posts a request. The business tier executes the business logic, the database collects/stores application specific persistence data, and the UI shows the data to the user.

There can be several benefits to developing using the monolithic pattern for well-defined and low-growth potential applications. In the discussion pitting monolithic and microservices-based architectures against one another, contextual opinions abound, but common arguments in favor of the monolithic patterns generally revolve around these four points:

• It’s simple to develop. There’s a single code base written in a single programming language, and many current development tools and integrated development environments (IDEs) are optimized to support the development of monolithic applications
• It can be simpler to test. For example, you can implement end-to-end testing by simply launching the application and testing the UI and results with an automated scripting tool.
• It’s simple to deploy. You just have to copy the packaged application to a server.
• It’s simple to scale. You turn up multiple copies behind a load balancer.

We’ve found that the relative weighting of the above points varies significantly based on the age of the application, the variety of capabilities the system is required to accomplish, and the relative familiarity teams have with the system. This doesn’t diminish a given organization’s decision one way or another but should be understood in context to the application’s goals and organizational capabilities in mind. As technology continues to evolve and more systems are being developed in an as-a-service modality, theses opinions may tend to change over time to reflect a more distributed-by-default approach.

For smaller projects, in the early stages of the project, the monolithic style can work well by leveraging pre-existing components and reducing the ‘number of moving parts’ and orchestration-level work required. As features are added, as the application grows and matures, there may be points in which new problems become difficult to overcome and old techniques cannot be applied. Many organizations find that the all-in-one approach (monolith) can lead to a number of indicators that point to a need for some amount of re-evaluation of architecture and design. This is where we find the common arguments against monolithic architectures and where organizations begin to consider microservices. Some indicators that the legacy monolithic systems may be candidates for other architectural approaches include:

• Managing technical debt becomes a full-time job. Often, this occurs when small and iterative changes are made to a large monolith without considering the entirety of the system, causing an ever-growing list of ‘things to fix.’
• It becomes hard to change without breaking things. The internal dependencies have become so complex that changes create unintended consequences.
• QA and test cycles take too much time. An ever-expanding set of use cases drives complexity and expense into the testing effort; and everything needs to be tested to ensure nothing was broken by the change.
• How it works becomes a mystery. It becomes an application that no one wants to modify because no one really understands what the downstream implications of even simple changes might be.
• It becomes married to the underlying technology. It isn’t portable or upgradable because specific technology dependencies are built into the code itself, even down to specific hardware at times, expanding this pain point to IT as well.

• Specialty teams arise based on the technology tier. Functionally-focused teams (UI, back-end, database, etc.) removes overall context from teams and allows them to focus only on one part of the overall system, further removing context from technical decision making.

As a very simple example, WordPress is an interesting software toolset that was designed as an online publishing platform but somehow finds itself in numerous other spaces including eCommerce and social media. As a starting point, WordPress provides an enormous amount of utility for very little effort and exemplifies this idea that starting with a monolith can be an easier path forward. The counterpoint, however, is that it’s not necessarily designed to accomplish all the myriad of tasks set before it, leaving it as a ‘jack of all trades, master of none’ at best, and more often than not, a system that while functional, requires an unexpected amount of operational maintenance to scale to meet the growing demands of those trying to build and expand at a business level. Even with a strong and versioned plugin model, interdependencies between plugins can become onerous to manage even for the simplest of deployments.

The weaknesses of a monolithic model for enterprise or large-scale use as compared to microservices are in the areas of agility, continuous delivery, availability, fault tolerance, resiliency and scalability.  With one replicated code base in a monolithic design, changes need to be carefully choreographed, are less frequent and are just harder to make than is typical with a microservices approach. That said, monolithic applications comprise the bulk of most enterprise applications; so moving to microservices requires careful attention to integration and migration.

Despite the weaknesses of a monolithic model and the momentum behind microservices, it is important for enterprises to understand that monoliths aren’t bad as long as their scope is limited. WordPress, for example is manageable as long as you don’t “overdo” the customization. It is when rampant customization and associated complexity make the monolithic application unwieldy, that enterprises often entertain “decouple the monolith” projects.

There are reasons to keep some of this simplicity with a microservices approach. Each new technology requires licenses, infrastructure, development and support skills, and sometimes additional operations and support tools. As time goes on, however, we’ve found that some of these arguments diminish in their impact – especially that of licensing and tooling, given the continued evolutionary processes even the underlying tooling has been going through. Being too restrictive on these inhibits an organizations performance. On the other hand, failing to provide a prudent amount of governance and standardization can result in a technology footprint that is too costly and may undermine the business agility promised by microservices.

Clients are advised to include critical aspects of the EA approach such as reference architectures and infrastructure standards.  Clients should strive to keep the standards and governance as light as possible but ignoring them is risky. This is a situation that requires leadership to exhibit a combination of technology and business acumen.

Allocating the “correct” scope of responsibilities to each of the microservices is critical to the success of a microservices approach.  Well-architected monoliths are made up of (what should be) cohesive modules in much the same way as microservices. In many cases, while somewhat of a simplification, well-designed and architected monoliths that adhere to common object-oriented software development principles tend to be more successful both in managing the risks of monoliths, but also in the transition to a microservices architecture. In this case, good fundamentals have enormous impacts on both the operational health but also the organization’s agility. As a word of warning, clients moving workloads from a monolithic pattern to microservices are advised to perform the necessary due diligence to determine the optimum division of responsibilities prior to forward engineering a microservices solution.

Essentially the weaknesses of the monolithic architecture are the strengths of microservices. There is greater agility, scalability, fault tolerance and more regular updates/releases with the microservices approach.

One of the major areas of risk that enterprises need to pay attention to when moving to microservices is security. Rather than securing one monolithic application, microservices introduces a larger number of independent services that need to be secured. The next section covers this key design element in greater detail.

Microservices and Security

Often overlooked, the use of microservices architecture doesn’t negate the need to significantly evaluate threat vectors and other security concerns, though, depending on the tools used and specific patterns used, it does offer an opportunity to both potentially simplify and improve the overall security posture of a given system. In evaluating these opportunities there is one single and critical factor to success for enterprises, regardless of size, industry or requirement: collaborative and collegiate engagement with the security team(s) involved early and often is the one thing development and operations teams can do to ensure a successful outcome.

Much like with other larger scale changes in technology, it’s not uncommon for security concerns to be ‘left until later’ as organizations work to understand capability and how it can be leveraged to the benefit of the business. As such, as a general sentiment, the security team(s) involved with any sort of new or different deployment strategy can easily be seen as blocking progress or slowing the overall system down. In an architecture designed to accomplish a high rate of change in an operationally consistent manner, it’s critical to bring this ‘move fast change often’ mentality to the security discipline as well.

Beyond software design and security best practices at a code level, there are numerous steps at a deployment and infrastructure level that can improve security posture and confidence from container-level vulnerability scans both at build and in real-time as well as process level tools to manage the exchange of certificates to validate the communications between one or many components. This, generally, has the effect of up-leveling conversation from firewall rules and intrusion detection and prevention tools to the security assurance outcomes at a functional level. Again, the collaborative effort on the part of all involved to achieve these functional needs and in balancing the performance, process and assurance needs of all teams involved is critical to the success of ensuring a secure microservices architecture without unduly sacrificing the ‘move fast’ mentality it enables.

As TechVision Research described in our recent report entitled “Evolving Against Vulnerabilities, Breaches, and The Next Cyber Attack” by Gary Rowe and Nick Nikols, NIST’s Cybersecurity Framework (CSF) is likely to become the basis for what’s considered commercially reasonable in regard to securing an organization’s infrastructure. The CSF is risk-based approach for developing and improving cybersecurity programs and can be applied to ensure better security is baked in throughout the microservices development and deployment process. We believe following a standardized approach like this is particularly important in addressing the distributed nature of microservices.

While still growing and maturing, there are a number of tools in the market that can be leveraged to help improve security visibility and posture. The list below shows a number of capabilities and both commercial and open source products that TechVision Research is monitoring:

	Commercial	Open Source
Vulnerability Scanning	Twistlock	Clair
API Gateway	Apigee, nginx plus, Kong	Kong Community
Application Security	nginx plus, Cloudentity	Istio

Table 1 – Sample microservices security tools

Lateral Approach to Governance

It would be easy to confuse some of the microservices mantra related to decoupled systems and leveraging ‘the best tool for the job’ as a potential risk to standards, supportability and, ultimately, increased cost of ownership. With a traditional approach to standardization at a technical implementation, language and library level, the perceived lack of control could seem to leave a lot of risk within the new operating system. Successful microservices architectures do not ignore governance, but rather look to build standardization and consistency at a pattern and process level rather than at a concrete technology level. This requires that a historically static tooling-driven approach to accomplishing governance within a large deployment be rearticulated and enabled at a less technology-bound level of the system such as the communications level (i.e. RESTful APIs).

Several sets of tools aim to help achieve this pattern and protocol-level standardization effort. One key set of tools that articulate ‘API Contracts’ act as a declarative tool to help define how systems communicate at a protocol level (HTTP) and decouple this communication from the implementation, allowing for multiple possible implementations based on any number of variables. These contracts are written in a known and structured format such that they can be leveraged in a number of manners from code to documentation generation. While these tools (such as the Open API framework, RAML and API Blueprint) are certainly still maturing, TechVision Research sees this toolset as a key means of enabling teams to conform to overall standards that interoperate between multiple possible implementation strategies.

Additionally, tools such as Istio in the open source community offer growing and increasingly more granular and stringent capabilities related to achieving consistent governance in an enterprise-level microservices deployment. Historically, ‘governance’ capabilities have tended to add significant time to deployment and management process and these tools and platforms built to accomplish similar needs while still achieving the deployment pace and speed of a microservices architecture are still working out how to balance these traditionally competing needs.

DevOps and Microservices

Microservices and DevOps are often lumped together and, while highly synergistic, are two very different things. Microservices, as we’ve described is a business-focused way of designing applications as independently developed and deployed services.  DevOps is the mindset, the processes, automated tooling, and appropriate organizational structures that contribute to better and deeper integration between development and operations.  While they can benefit from each other and are focused on similar end-game outcomes, their areas of impact and focus tend to be very different.

Where the microservices architecture pattern benefits the most from a DevOps approach is in the level of automation and consistency required to enable and operate deployments at scale. A Microservices approach essentially forces a reassessment of the level of automation and the size and shape of organizing concepts that favors many smaller moving pieces above a few complex ones. In order to achieve a stable environment and repeatable, reliable deployments, leveraging the automation focus of the DevOps discipline can be a critical key to success post-development. DevOps automated continuous delivery and continuous integration capabilities can be more effective in supporting a microservices architecture by providing delivery speed and assurance that traditional organizational approaches cannot.

While this report focuses on microservices and we will continue to describe areas of overlap, the concept and patterns related to DevOps will be covered in greater detail in future TechVision Research reports.

Microservices and Containers

A container is the bundling of an application and its computing dependencies into a single object. A container is the same in development, testing and execution and can be thought of as a sandbox. It can be thought of as operating system-level virtualization in that they are designed to run anywhere and therefore are independent of the external environment.

Containers and virtual machines are complementary. VMs excel at providing extreme isolation while containers are very lightweight and perfect as a unit of software delivery in support of microservices.

Microservices vs. Other Architectures

As we said earlier, microservices leverage many of the concepts that have evolved over several decades. In particular, microservices has been characterized as Service Oriented Architecture (SOA) ‘done right’ as there are several concepts that are similar. Microservices’ goals are similar to SOA, but the goals and the supporting approaches have evolved, and advocates are purporting that microservices have overcome at least some of the weaknesses of SOA.

Traditional service-oriented architectures are typically designed to maximally leverage shared resources while a microservices architecture assumes that smaller, less coupled components. The side effect of a shared resources design is a lot of physical coupling, where each service shares a monolithic database, an object-relational mapping layer, and lots of shared implementation elements. Architects are also drawn to single sources of truth to eliminate duplication, which encourages “smart” architectural elements like Enterprise Service Buses to handle chores like transformation and orchestration. If you look at SOA architectural goals, the desire is to encapsulate behavior and secondarily share resources. However, traditional SOA architectures make isolated change hard: when everything is highly coupled at the implementation level to share resources effectively, that coupling hinders isolated change.

In contrast, a microservice architecture emphasizes decoupling, appropriate duplication, and simple connections with smart endpoints. This approach optimizes for incremental and focused impact for any change.

For the purpose of comparison, we’ve also included a more typical Model View Controller (MVC) architecture for consideration along with SOA and a prototypical Microservices design to provide context.  MVC applications divide applications into three constituent parts that can optionally be deployed as separate assets. In very simple terms, this design pattern’s components can be defined as:

• Model – Expresses the data and business behaviors of the problem space
• View – Presents the output of the model and controller to users for interaction and manipulation
• Controller – Accepts input and expresses it to be consumed by the model

Comparing the three models on common software and operational considerations, we see some significant similarities and differences that are notable:

	SOA	MVC	Microservices
Cohesion	Moderate	High	Low
Complexity (Component)	High	Moderate	Low
Complexity (System)	Low	Moderate	High
Consistency	Very High	Moderate/Low – multiple artifacts for a given concept requires synchronization	Can be low
Simultaneous Development	Low – single point of integration can cause significant risk of overlapping updates	Moderate – Decoupling major concerns allows for more teams	High -loose coupling enables many concepts to be developed in parallel
Ease of Updating	High when configuration management discipline in place, often mitigated by multiple environment promotion ‘tests’	Moderate risk of component-level updates causing unexpected outcomes.	Low if not automated, high otherwise
Navigability	High – one place to look and one set of structures defining code organization	Moderate/Low –	Low – many components and repositories require strong and overarching service catalog view
Learning Curve (assuming proper documentation)	Low / Moderate depending on the application scope	Moderate given multiple components	High – multiple new and emerging technologies may also present a ‘moving target’
Underlying assumptions	Scarce resources, static deployment environment that is consistent for a long time	Need to update certain ‘layers’ of a given system independently along functional or work-type categorical lines	Automation is in place to handle many similar moving parts at scale

Table 2 – Comparison of application architectures

Enterprise Microservices Requirements

As we said earlier, most technical organizations aspire towards a better means of building, deploying and updating applications. The challenges lie in how to get there from where most enterprises are today…and the place they are today is generally supporting monolithic applications that have been the mainstay enterprise foundation over the past several decades.

At a high-level, most enterprises are looking to modernize, want to be more agile, are looking to move faster and want to better connect with customers, prospects, employees and partners. The problem with many of the monolithic applications and associated architecture models is that it is not easy to or timely to make changes.

A key enterprise requirement (or aspirational goal) we often see is that organizations want to be like an Amazon or Netflix; enterprises are looking for a robust, scalable, adaptive and cost-effective model they believe is represented by these innovative technology leaders. But most enterprises are not ready to live up to these cloud-native companies from a technical perspective, an investment perspective or have the risk tolerance to jump into the deep end of the pool. Many of the marquis cloud-native organizations don’t have the backlog or technical debt of legacy applications and have relatively larger budgets with market-facing requirements for speed and scale that most established companies don’t. Microservices at scale can be very complex and expensive when approached from a traditional ‘Enterprise Architecture’ perspective and most organizations don’t currently have the need for that degree of scalability and flexibility.

That said, the enterprise model changes quickly in the face of one of those fast-moving startups encroaching on an established organization’s market and revenue. Rapid loss of market share and competitive pressure may accelerate the movement to a microservices architecture. Global 1000 organizations have seen early stage companies mature overnight and are anxious to learn how to mirror their success but recognize that they probably don’t need to move (and probably can’t move) so quickly as there are many layers of processes, systems, customers and regulatory controls that are being handled with the current systems and services.

We’ll now examine microservices architecture in greater detail and then conclude with some actionable recommendations for our clients to consider.

Microservices Architecture Details

Microservices are an architectural pattern focused on business capabilities. Microservices decompose applications according a concept of single responsibility in which each microservice is activated via an API and executes discrete business capabilities (e.g. product catalogue, customer profile, reservation, inventory, order, billing, fulfillment) within a specific and well-defined context. The interfaces reside on atomic application platforms that contain separate database storage, integration flows, and web application hosting.

By separating concerns onto separate platforms and not sharing database instances or web application hosts across services, every team is can choose different runtime languages and frameworks for its own microservice. Also, every team is free to evolve its data schemas, application frameworks, and business logic without impacting other teams. This empowers each team to be a “self-contained unit” and fully accountable for the results.

This does not mean that adopting a microservice application architecture turns development into the “wild west” where anything goes, and rules don’t exist. The concepts of polyglot programming and polyglot persistence referenced in the previous paragraph are still bound by enterprise architecture and data management “rules”. Core concepts expressed through the overall design of a system may find organizing patterns around groupings of business concepts where specific rigor and tactics may define more stringent behavioral rules (like immediate consistency of data vs. eventual consistency) or around similar sets of business concepts. For example, a microservice managing user authentication data may require a more stringent set of consistency and performance requirements whereas a service that accepts website telemetry data for analysis could likely handle an eventual consistency structure even with meaningful delays in data availability.

In this section we’ll describe the basic components that comprise what we generally consider to be microservices. It includes technology and also how organizations are approaching microservices. Key concepts we’ll review include:

• A Microservices “Mindset”
• Modeling microservices around business domains
• Application development based on small services
• Independent, automated delivery
• Minimizing centralization service management
• Different programming languages and storage technologies

Microservices is a philosophy, a mind-set, a new type of development organization and leadership that focuses on empowering developer and development team leaders and should be supported by business leaders and executives throughout the company. We’ll start by describing this microservices mind set.

A Microservices Mindset

Achieving microservices success starts with a new perspective on development we call a microservices mindset. As a matter of fact, many developers will have to unlearn many of the core principles they were taught in their technology training.

First of all, microservices are not meant for reuse (SOA was all about reuse). Think of microservices as disposable and replaceable components. If you’ve ever owned a component audio system, you get the idea; you can replace the speakers without replacing everything else. Microservices are built to do one thing and if thinking about using them to do something else, throw them away and build anew. Most developers were trained to design systems that eliminated code duplication and data redundancy, but microservices require data redundancy to maintain their independence.

Microservices also require a different attitude toward failure. Many developers have designed software with the assumption that failure is bad and must be avoided. In a microservices world, though, developers are encouraged to expect that failure will happen and to prepare for it. Services designed in this new paradigm should intentionally and gracefully degrade when things fail and do so with minimal human intervention. This approach means to solve Werner Vogels’ ‘All things fail all the time.’ problem not only from a hardware level (as has been the case in some traditional infrastructure deployments) but from within the software itself. In fact, forward-thinking organizations employ chaos testing that intentionally causes failure to simulate random service failures (even in production systems) to validate that the application reacts and recovers in an appropriate manner.

Microservices are built for speed.  Developers leverage a number of tactics such as Agile development, DevOps, continuous integration and delivery, automated testing and release in order to reduce the time from ‘idea’ to ‘deployed’. Key to this approach is a relentless approach to finding those things that add time to the overall deployment pipeline and automating them such that they require fewer (even zero) points of human interaction to come to a conclusion.

Finally, microservices are ever-evolving. To properly leverage them at scale, you need to continually learn new and emerging technologies (containers, orchestration platforms, networked applications) and gain deep understanding of business domains (from nose to toes). To make it all work out right, continual education in-depth is not only desired, but required. Interestingly, one might assume that engineers and people in the IT space are driven by learning as technology is ever evolving but, in our experience, the level of continual education can, for some, stretch individuals’ comfort zone a bit more than expected. Being both aware of and supportive in this transition is as critical to the success of a microservices implementation as any other technical detail discussed in this document.

There is also a different approach to standards in that standards are applied at a different level (usually at the HTTP and messaging format level) and more tools and tested code libraries distributed and with de facto standard version control via a modern source control management tool (such as git). The model is open source (even internally) with sharing and collaboration as key measures of success versus a more formal, rigidly defined process and concrete standard. More generically, standards within a microservices architecture seek to articulate the ‘how’ (how do we make decisions, how do we communicate, how do these components deliver their logs, etc) rather than a rigid ‘what’ (we use this logging library, we use this specific object structure, etc.).

The mindset also requires being OK with a lot of choices; flexibility means the development team can make informed yet independent decisions about programming language, data schemas, and database technology with the understanding that they will, in-the-end, support the choices made in production.

Modeling Microservices Around Business Domains

Microservices are designed, built and deployed as business-centric services. For example, in our hospitality industry example, a business-centric microservice might be broken into customer domains, distribution domains and financial domains to model out the business focused services. Within the distribution domain we might focus on developing microservices that support the reservation process as highlighted in the figure below.

Figure 4: Applying Microservices to a Reservation System

Team structures focus on business domains.  While traditional (e.g. SOA) team structures incorporate development teams aligned with business domains the alignment of other teams participating in application development is stratified across technology layers.  The technology centric teams are matrixed-managed to service many different business domain teams and gain only limited knowledge of the individual business domains.  Microservices teams are structured around business domains first.  Team members from across the different technology layers work together as a single team to meet the needs of a specific business domain.

Like the services, the teams are tightly focused on the business domain.  This enables them to build deep understanding of the business domain and ongoing relationships with their business counterparts.  Clients are advised to recognize that these are strategic assets that greatly improve business agility (the critical ability to precisely and predictably hit the targets defined by the business need with speed and quality).

Application Development based on Small Services

Using the model above, you can break up the Hotels.com application to align with the various domains.  As shown in the screenshot below, the different components are combined within a client context (in this case, an internet browser).

Figure 5 – a browser UI displaying information from different business domains

The advantage in using the microservice pattern is evident. Each portion of the screen represented by a business domain can be modified or replaced at any time.  The components are small in scope and can be automatically released in minutes.  The user sees the modified application by simply performing a screen refresh.  No big bang event is required to evolve the application to test or meet market needs, however you will need tooling and methods to achieve these results; specifically, independent and automated delivery.

Of specific note, while the microservices underlying the example are distributed in nature, the front-end (web page) must still be served and rendered into one cohesive unit for the user to experience. There are many different tools with various approaches and opinions as to how best to achieve this including frameworks that pre-render everything at the web server to those that require the client to load data from each microservice individually in parallel. The choice to pre-render or require clients to request data from the browser is one that has more to do with the required user experience and web page performance metrics and behavioral assumptions than anything else. Consideration of which pattern to leverage is often not an all-or-nothing either and careful consideration should be made when designing web and other applications from a microservices approach. As this new back-end services pattern has grown, so have the myriad of front-end capabilities and patterns.

Independent, Continuous Delivery

The goal of the microservice pattern is to deliver small, domain-bounded, and independent services.  If built correctly, microservice components fit hand-in-glove with the practices of agile programming, continuous integration, and especially continuous (automated) delivery to realize the following benefits:

• Low risk releases. The primary goal of continuous delivery is to make software deployments painless, low-risk events that can be performed at any time, on demand. By applying patterns such as blue-green deployments it is relatively straightforward to achieve zero-downtime deployments that are undetectable to users.
• Faster time to market. It’s not uncommon for the integration and test/fix phase of the traditional phased software delivery lifecycle to consume weeks or even months. When teams work together to automate the build and deployment, environment provisioning, and regression testing processes, developers can incorporate integration and regression testing into their daily work and completely remove these phases.
• Higher quality. When developers have automated tools that discover regressions within minutes, teams are freed to focus their effort on user research and higher-level testing activities such as exploratory testing, usability testing, and performance and security testing. By building a deployment pipeline, these activities can be performed continuously throughout the delivery process, ensuring quality is built in to products and services from the beginning.
• Lower component costs. Any successful software product or service will evolve significantly over the course of its lifetime. By investing in build, test, deployment and environment automation, we substantially reduce the cost of making and delivering incremental changes to software by eliminating many of the fixed costs associated with the release process.
• Better products. Continuous delivery makes it economic to work in small batches (microservices). This means you can get feedback from users throughout the delivery lifecycle based on working software. Techniques such as A/B testing enable you to take a hypothesis-driven approach to product development whereby you can test ideas with users before building out whole features. This means you can avoid the features that deliver zero or negative value to your businesses.

Minimizing Centralized Service Management

Microservices only use centralized service management when ABSOLUTELY NECESSARY. All functions and controls that can be independently managed and controlled should be. As such, patterns such as Event Sourcing have become common partners with microservices architectures to ensure a distributed but service-level opt-in (as opposed to centralized delivery management) to events passing through a global event stream.

Solution Blueprint: A Framework for Adopting Microservices

Microservice architectures have significant advantages over traditional architecture models but require a different mindset and significant planning and staffing to prepare for the changes. This section will describe the proper framework and types of applications that fit best within a microservices design approach.

The first step is to determine if your enterprise is really prepared for this movement. If you are prepared the next step is to determine which applications are candidates to m

Understand your current environment; Are you ready for Microservices?

Most large enterprise organizations are not yet ready for microservices at scale but can begin to take steps to prepare. As we’ve discussed earlier, it starts with a culture and a mindset that promotes small teams and aspires towards rapid deployment, continuous monitoring, continuous deployment and the automation of everything. In determining your readiness for microservices consider the following factors:

Interface Awareness and Contract First Approach

Throughout this document we’ve described the need for the technical boundaries and interfaces of a microservice to be well known. This general pattern is no different than that of interface design from an Object-Oriented approach related to interfaces and communications protocol.  A significant number of tools have emerged that can assist in this effort, even to the point of generating basic code structures based on API contracts written in a well-known format. This set of capabilities is still emerging, though the OpenAPI Specification^[3] and others like it, seek to help make this critical step in the design process easier and more functional than ever before. We at TechVision Research both see this as a novel approach to the problem, but also an intriguing application of automation that, once it has time to further mature, is likely to have a large impact on the microservices design process.

Culture of Automation

Enterprises that systemically automate anything that can be reasonably automated are in far better position to support microservices. As we discussed earlier, the challenge of testing and managing all of the moving pieces associated with microservices can be far better managed with automated testing, automated provisioning, and automated deployment.

Continuous Monitoring Program

As your microservices program grows, the number of libraries, templates, build processes and moving parts to be managed will grow exponentially. A strong continuous monitoring program will help to keep track of these elements, help to ensure they are healthy and provide alerts if problems are detected. Monitoring is, of course, necessary with monolithic applications as well, but the scale of processes to be monitored is much smaller.

Automated Testing

Much like continuous monitoring, the scale of testing grows exponentially with microservices and most organizations will not be able to manage this without a significant investment in automated testing.

Microservices Framework

Figure 6: Microservices Template

The above reference architecture template extends our hospitality industry use case and describes the areas to be included within an overall microservices framework. It also includes the connections we commonly see between major components.  The above template starts with business capabilities are then factored into independent microservices.  Microservices expose a small, easy to understand business domain and need to rapidly adapt to changing business demands. Applications always access microservices through simple APIs.

Microservices Best Practices

This section describes microservices best practices for the enterprise. TechVision’s recommended best practices fall into seven foundational categories that represent key areas organizations should consider when establishing or expanding a microservices program. These include core principles, design considerations and implementation approaches. The core best practice pillars for microservices are:

• Manage microservices and APIs as “business products” from conception to retirement
• Control service access based on business requirements, not technical constraints
• Design for service unavailability (failure)
• Manage SLAs
• Support service discovery and definition
• Architect an appropriate level of microservices granularity
• Consistent data management

We’ll now provide additional context and advice for each best practice area defined starting with the first on the list; the business product focus. This involves initially assessing how this effort can drive revenue streams, cost savings or some type of competitive advantage. Ultimately the resultant program could be marketed and managed as a business asset.

As these services are deployed, it is critical access based on business requirements and perceived business risk and not let technology constraints impede these goals. Once microservices are deployed and in the wild it is impossible to control consumers and consumers will often identify ways to use a service that are radically different from how it was originally envisioned. The focus needs to be on building a robust, rigorous and flexible identity management foundation for your microservices program; it can be thought of as your new security perimeter. Increasingly, identity and security services will also be based on microservices as described in TechVision’s report “How Microservices can improve your IAM Strategy” by Doug Simmons, Nick Nikols and Gary Rowe published in December 2017. Any microservices program needs to ensure that the right access is being provided to the right services at the right time.

Microservices should be designed for service unavailability or failure. Services will fail, but a well thought out microservices program will look to minimize the damage caused by a failure. Enterprises need to provide resilient behavior over microservices by designing for graceful downgrading and temporary outages.  The program leader needs to make sure the tools are in place to detect, diagnose, and remediate failures. Like a boy scout; you want to be prepared.

Since microservices bring together independent services, it is critical that there are well defined Service Level Agreements (SLAs) and that these SLAs are proactively managed to ensure performance to these agreements. Furthermore, putting logging and aggregation tools in place to measure and analyze performance provides the data to support enforcing SLAs.

Service discovery and definition best practices requires well-defined and documented services in an online repository or catalog with simple consumer access. Then in the execution environment it is important to make sure that there are the proper microservice management capabilities (discovery, configuration, routing, etc.) in place for consumption.  The services specifications must be designed to support versioning and eventual depredation.

As we discussed earlier, a core part of microservices is offering the appropriate level of service granularity. More specifically, the service granularity should be aligned with a RESTful API or a specified event structure. The services should have a bounded context and should provide a useful business service. Furthermore, the microservice databases should not be exposed directly to other services.

Last, but not least, there should be consistent data management. It should at least be designed for eventual consistency.  In a networked application, where microservices maintain their own data, the true state of an entity may be inconsistent among services.  That’s why a room reservation that is shown as booked in the app is followed up with an email. The email indicates the room inventory has been updated with your explicit details and confirmed in the database of record.  Data should also be explicitly replicated where needed, using a master data management paradigm.

Microservice leaders should also look for opportunities to use in-memory data grid technology for low latency and scaling across microservices. This aligns well with the model of a data microservice, with a small defined set of data rather than focusing on a large integrated data model.

These best practices are a good starting point to consider as you embark upon your microservices program. But is it the right time to proceed? Are you use cases compelling enough? The next section will provide some guidelines for evaluating microservices.

Evaluating Microservices

We talked earlier about enterprises readiness for microservices. We’ll now consider if an enterprise should move to microservices. There are some real advantages, but there is no free lunch. There is added complexity and corresponding costs associated with the microservices approach, but also many advantages.

We have learned a lot from early enterprise experience in microservices and the following is our assessment of some of the pros and cons of moving to microservices. This should be a useful tool in assessing how, when and where your organization will move towards a microservices architecture model.

Pros:

• Deployability: more agility to roll out new versions of a service due to shorter build+test+deploy cycles. Also, flexibility to employ service-specific security, replication, persistence, and monitoring configurations.
• Reliability: a microservice fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith.
• Availability: rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith.
• Scalability: each microservice can be scaled independently using pools, clusters, grids. The deployment characteristics make microservices a great match for the elasticity of the cloud.
• Modifiability: more flexibility to use new frameworks, libraries, data sources, and other resources. Also, microservices are loosely-coupled, modular components only accessible via their contracts, and hence less prone to turn into a big ball of mud. Dynamic discovery and binding via a registry (e.g., Apache ZooKeeper, Netflix Eureka) is sometimes used for location transparency.
• Management: the application development effort is divided across teams that are smaller and work more independently.
• Design autonomy: the team has freedom to employ different technologies, frameworks, and patterns to design and implement each microservice, and can change and redeploy each microservice independently

Cons:

• Deployability: deployment becomes more complex with many jobs, scripts, transfer areas, and config files for deployment.
• Performance: services will likely communicate over a network using network protocols, whereas services within the monolith may benefit from local calls. Also, if the microservice uses dynamic discovery, the registry lookup is a performance overhead.
• Fault tolerance: we mentioned earlier that microservices should be designed to anticipate failure and downgrade gracefully when needed.  This requires thinking through retry attempts, queueing, user warnings, and other techniques not required for monolithic applications.
• Availability: if you use a registry for dynamic discovery, unavailability of the registry may compromise the consumer-service interaction.
• Modifiability: changes to the contract are more likely to impact consumers deployed elsewhere, whereas in the monolithic model consumers are more likely to be within the monolith and will be rolled out in lockstep with the service. Also, mechanisms to improve autonomy, such as eventual consistency and asynchronous calls, add complexity to microservices.
• Testability: automated tests are harder to setup and run because they may span different microservices on different runtime environments.
• Management: the application operation effort increases because there are more runtime components, log files, and point-to-point interactions to oversee.
• Memory use: several classes and libraries are often replicated in each microservice bundle and the overall memory footprint increases.
• Troubleshooting: isolating an application problem becomes more complex as many teams may become involved in replicating the issue based on intermingled log entries and interactions of the various components.

Summary and Recommendations

In this enterprise-focused research report, we’ve articulated a number of details identifying the structure, patterns and even some of the roots of how the microservices architecture has both grown in popularity and also matured in just a few short years. While we are interested and optimistic in our guidance with respect to this architectural pattern and the ecosystem that is growing behind it, we’ve been careful to also not to assume this pattern, like any other, is a panacea. We believe firmly that organizations embarking on a journey to leverage microservices should be clear in the value it is to the enterprise and leverage that clarity to gain a shared commitment to the effort at a business level before anything more than simple proof of concepts are accomplished at a technical level.

Beginning a journey of building a microservices capability within any organization is key and begins, like any transformational effort, with buy-in and support from executives who both see and can clearly articulate the values to the business. Unlike other organizational changes, due to the open source ‘culture’ that we see as a key success factor, executive support is key and should be leveraged both to bring awareness to the effort throughout the company, but also to demonstrate the collaborative and open communication patterns in order to drive confidence within the teams leading the change itself. While seemingly innocuous, this simple step can make or break this type of effort very early in the process.

As teams begin to experiment with the architecture and operational patterns to support it, there are a number of considerations to keep in mind as your team(s) begin to move forward:

• Set expectations with executives, peers and teams that failure is both likely and welcome. Commit to working through failure in order to create an intellectually ‘safe space’ in order to encourage experimentation.
• Reinforce the ‘experimental’ early and often related to testing out the design in order to reinforce the ‘disposable’ attitude toward components.
• Encourage and highlight failure in a directly positive light. As the organization learns, leverage this to improve traditional root cause analysis processes to go beyond ‘human error’ to the underlying and tangible causes.
• Get help from outside your organization. This doesn’t mean you should have someone else do it for you but look for a consulting or engineering firm that will partner and supplement your teams who has direct experience in these design and architectural patterns.
• Research and understand the impact of open source licensing to your business and product(s) – specifically how your legal team(s) may define software distribution and redistribution. Work with teams to create an open source licensing and use policy.
• Commit to an automation-first approach. Keep a focus on overall operational manageability as the direct outcome of this practice.
• Incubate a ‘builder tools’ team who serves the needs of the developer within your organization who focuses in on far-reaching automation for repetitive and key tasks.
• When aligning teams along product (not project) lines, ensure that teams are multi-disciplinary and include product management, project management, test, operational and development roles. Note that individuals may play multiple roles, but that the roles themselves must be identified and accounted for.
• Identify patterns and functional requirements first, then look to specific tools. Of specific import, you may want to proactively investigate a number of critical capabilities. Note that some capabilities may be achievable within the same or similar tools but organizing them so that they are loosely coupled is just as important here as it is in your microservices software. See Appendix A for specific examples of capabilities and current (June 2018) open source options.
• When looking for new tools, look for emerging and open source tools first and take a critical look at the total cost of ownership only when committing. The value of experimentation at this level can help to build working knowledge around new capabilities that will be useful even if another choice is made.

As we’ve described in this report, microservices provide tremendous opportunities for enterprises but should be carefully navigated, tested and managed like any new foundational program. Good luck on your journey and stay tuned other TechVision reports covering new IT and development models.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skill sets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

Appendix A – Key Technical Capabilities and Open Source Options

The following are a list of capabilities and current (June 2018) open source tools available related to the need. Note that some of the listed tools may have commercial offerings and that mentioning them here is not an endorsement of tooling that will be right for any given organization. In many cases where specific tools may accomplish multiple capabilities, we’ve included links to point to the specific capability wherever possible.

• Configuration Management
  • Chef
  • Puppet
  • Ansible
  • SaltStack
• Application Performance and Telemetry
  • Elasticsearch
  • OpenTracing Standards
• Container Management
  • Kubernetes
• Continuous Integration
  • Jenkins
  • Drone
  • Gitlab CI
  • GoCD
• Continuous Test
  • Serenity and Selenium
  • Apache JMeter
  • Rest-Assured
  • Postman
• Continuous Deployment
  • Chef
  • GoCD
  • Gitlab CI (Kubernetes support as well)
• Secrets Management
  • Kubernetes Secrets
  • Vault (Hashicorp)
• Service Discovery
  • Consul
  • DNS
• API Gateway (Routing, App Security, etc.)
  • Kong API
• Vulnerability (CVE) Scanning
  • Clair (CoreOS)
• Security Monitoring/Scanning
  • OpenVAS
  • OSSEC
• Endpoint and Interservice Communications Security
  • Letsencrypt
  • Istio

^[1] thenextweb.com “Everything Fails All the Time” by Werner Vogels

^[2] Note that this is only an example of how an application of this type might be architected, it is not meant represent the actual application structure used in or recommendations for the development of the Hotels.com application.

^[3] https://swagger.io/specification/