architecting for speed: how agile innovators accelerate growth through microservices

1

ARCHITECTING FOR SPEED

How agile innovators accelerate growth through microservices

Jesper Nordström Tomas Betzholtz

2

Cutthroat competition requires enterprises to transform how they build and deliver software

In a world where software has become the key differentiator, enterprises are forced to transform the way they build, ship and run software in order to stay in the game. Competitive pressure requires applications to be rapidly and continuously upgraded with nonstop availability, and companies that lack the capacity to experiment, innovate and get new features out quickly, will be at disadvantage.

This is driving many IT organisations to adopt the software design model known as microservices architecture, which quickly is gaining traction as a new way to think about structuring applications, and is changing the fundamentals of enterprise application management.

Managing complex enterprise systems is a challenge and many enterprises still sit on large, monolithic applications with huge unmanageable codebases that have become increasingly difficult to maintain. Adopting a microservices architecture where applications instead are built as suites of services enables them to not only become more agile but also to cut costs and increase stability.

January 2016

3

“Many enterprises still sit on large, monolithic applications with huge unmanageable codebases that have become increasingly difficult to maintain.”

The problem with traditional software architecture and monolithic applicationsEnterprise applications have traditionally been built as monoliths with all functionality in a single process. These monoliths cause increasing frustration, especially as more applica-tions are being deployed to the cloud. Monolithic applications are fine for small scale teams and projects but become problematic at larger scale when many teams are involved because they don’t allow organisations to improve functionality rapidly enough.

• As developers write code to add new features, the codebase grows, and over time it becomes hard to know where a change should be made because the codebase has become so large. Code related to similar functions begin to proliferate, making fixing bugs or implementations complicated. Doing continuous updates requires an exponen-tially growing amount of coordination.

• New developers must often spend months learning the codebase before they can begin to work because it requires an understanding of how any change will affect the entire codebase, and a broken update can cause the entire application to crash. Even seasoned teams worry about making changes or adding code that unexpectedly might disrupt operation—why even simple changes can be debated endlessly.

• Change cycles are tied together and a change made to only a small part of the applica-tion requires the entire monolith to be rebuilt and deployed. Updates therefore become more painful and less frequent, contributing further to the fragility of the application.

4

This is why many enterprise IT organisations are spending weeks carefully coding and testing before any updates can be rolled out to end users.

When things go wrong (which they often do), the blame game starts, and the business starts to search for outsourcing alternatives because they’re losing trust in IT’s ability.

The rise of microservicesMicroservices has emerged as a solution to many of the problems associated with large, monolithic applications. It’s the first architectural style of the DevOps era and embraces the engineering practices of Continuous Delivery. It’s also an example of evolutionary architec-ture, which supports incremental change as a first principle.

“Microservices has emerged as a solution to many of the problems associated with large, monolithic applications.”

Successfully implemented, microservices can deliver substantial increases in the speed and agility in which companies build and deploy software. The cost required to deliver an appli-cation is typically much less and systems become more resilient. Development time can go from months to weeks. Businesses such as Dropbox, GE and Goldman Sachs have seen development lead times cut by 75% after transitioning to microservices.1

Microservices as an evolutionary architecture Conventional wisdom asserts that architectural elements are difficult to change. However, the world of software isn’t static but evolves continuously why a fixed view of architecture will be short lived. Architecture is abstract until operationalised and it’s hard to determine the long-term viability of any architecture until it’s been implemented and upgraded 2.

Evolutionary architecture designs for incremental change as a first principle. Change is difficult to anticipate and has traditionally been expensive to accommodate later on, but when evolutionary change is built into the architecture, change becomes easier and less costly—allowing changes to development practices, release practices and general agility.

A key benefit of evolutionary architectures is the ability to experiment. Several versions of a service can exist within the ecosystem, which allows for experimentation and gradual replacement of existing functionality. This means organisations can spend less time specu-lating about story backlogs and instead engage in hypothesis driven development.

What are microservices?The microservices architectural style is not an agreed architecture with a defined set of frameworks. In short it can be described as a conceptual approach to developing applica-tions as suites of small, loosely coupled and composable services working together, where

5

each microservice is a complete autonomous process that can be programmed in any lan-guage and managed separately.

Each microservice is designed to perform a single function representing a small business capability and talk to other microservices via language-agnostic APIs. The services are inde-pendently deployable and scalable. In a conventional architecture, a single database sup-ports one monolithic application. In microservices architecture, each service has its own database. Together, these services and their databases deliver the user experience.

Let’s look at some of the characteristics of microservices in more detail:

Microservices are autonomous

The core idea of the microservice architecture is that any one service is autonomous and can be changed and deployed independently, without needing to change any other part of the system. Therefore, microservices must have minimal dependency on one another (loose coupling). To prevent the applications that consume their data from binding too tightly to them, and make it easier to roll out future changes, services should expose only necessary information.3 A loosely coupled service knows as little as needed about the services with which it collaborates. This means integration styles should be avoided that tightly binds one service to another and cause changes inside the service to require a change to consumers (the “calling” program). The number of different types of calls from one service to another should also be limited.

Microservices communicate via language-agnostic APIs

Microservices communicate with each other through language and platform-agnostic appli-cation programming interfaces (APIs), which means that they can be developed in any pro-gramming language that is best suited for the task at hand.

Microservices perform a single business function

A key characteristic of microservices is that they focus on doing one thing well and have clearly defined interfaces (bounded context). Keeping the service focused on an explicit boundary, namely a specific product feature, makes it is clear where code lives for a given piece of functionality, while avoiding that the service grows too large. Every component of a microservice should be focused on the same task. This makes it easier to modify the behaviour of a part of the system, since it reduces the number of places where code needs to be updated to a single service, and the change can be released promptly. When a behaviour requires changes in several places, many services must be released at once to deliver that change, which takes more time and involves more risk.

Microservices are small

Codewise, microservices are usually around 100 lines, but can be up to 1000. However, rather than count lines of code when identifying the scope of microservices, it’s better to look at the functionality the service needs to provide, and how it relates to other services. Microservices should be “minimal but complete”4. A general rule is that a microservice should be small enough to be managed by a small team, and its conceptual model should

6

be able to “fit in your head”. If the codebase feels too big, breaking it down makes sense. A microservice should be the responsibility of exactly one team, but one team can be respon-sible for several services.

Microservices are managed by decentralised, cross functional product teams

The ideal organisation for microservices has small, empowered teams where each team is responsible for a business function composed of a number of microservices which can be independently deployed. Teams handle all aspects of software development for their micro-services, from conception through deployment, and therefore feature all roles necessary to deliver these services, such as product owners, architects, developers, quality engineers and operational engineers. This organisation design is consistent with Conway’s law5, which says that the interface structure of a software system will reflect the social structure of the organisation that produced it.

MICROSERVICES ARCHITECTURE

User Interface

Business Logic

Data Access Layer

DB

User Interface

Microservice

Microservice Microservice Microservice

DB DB DB

MONOLITHIC ARCHITECTURE

Microservice

DB

The microservices premium (Image adapted from martinfowler.com)

The building blocks of microservicesThe idea of microservices isn’t new. Google, Amazon and Facebook have been using micro-services for more than ten years. Each time a search is performed on Google, about 70 microservices are called out before results are returned6. Enterprises tried to achieve the benefits of microservices through an approach called service-oriented-architecture (SOA), which mainly failed due to poor governance, design and the lack of critical building blocks required for large-scale adoption. However, with the rise of DevOps and the development of the three key building blocks required, the benefits of microservices are now accessible to everyone. These building blocks are:

• Containers

• Scalable cloud infrastructure

• APIs

7

DEVOPSMICROSERVICES AND API:SCONTAINERS

THE BUILDING BLOCKS OF MICROSERVICES

SCALABLE CLOUDINFRASTRUCTURE

The building blocks of microservices

Containers: the launchpad for microservices

Just like containers revolutionised the shipping business, software containers have formed a standardised frame for all services, transforming how developers build and deploy applica-tions. Containers reduce complexity and enable developers to scale applications both faster and cheaper. Docker has today become synonymous with the container technology. In the future, every large application will be a distributed system comprising dozens of microser-vices running in their own containers.

Containers package a piece of software in a complete filesystem comprising everything it requires to run, which ensures it will run the same every time, independent of the environ-ment it is running in. By containerising the application platform and its dependencies, var-iations in OS distributions and underlying infrastructure are abstracted away7. This makes it easier to move applications from the workstation where they are coded to the clusters of computers that serve those applications to users. Compared with virtual machines, contain-ers have a very small footprint, which means that a single server can host far more contain-ers than VMs. They can also be launched in mere seconds, compared to several minutes for virtual machines.

Scalable cloud infrastructure

Virtualisation as we have known it can no longer keep pace with the demands of microser-vices and next-generation applications, delivering the necessary resources on demand to effectively scale and operate services. With DevOps emerging as a new way of managing development and operations, virtualisation is also losing one of its principal benefits: run-ning different guest operating systems on the same physical server8.

The fundamental principle of virtualisation: dividing a large and costly server into numer-ous virtual machines, is making way for new cloud architectures that are reimagining how data centres work. Rather than split the resources of individual servers, a software layer aggregates all the servers in a data centre into one massively scaled virtual computer to run highly distributed applications.

These emerging data centres are made up of inexpensive commodity parts with small, inex-pensive servers. They lack the computing power of traditional state-of-the-art data centres but due to their large number, the result is much more powerful. The new level of abstrac-tion makes an entire data centre seem like one huge supercomputer9 but the system really

8

consists of millions of microservices inside their own Linux-based containers—bringing the advantages of multitenancy, isolation and resource control throughout every container.

As scaling requirements grow and applications increase in complexity each day, every devel-oper and IT organisation will soon be affected by these changes. Every data centre—public, private or hybrid—will soon be adopting hyperscale cloud architectures10. This is bringing new cloud economics and cloud scale to enterprise computing, and enabling new kinds of businesses previously not possible. The data centre operating system allows developers to build distributed applications easier and safer without limiting themselves to the plumbing or limitations of the machines, and without being obliged to desert their preferred tools.

This new intelligent software layer will relieve IT organisations, often seen as innovation bot-tlenecks, from manually configuring and managing individual applications and machines, and instead enable them to spend more efforts on agility and efficiency—becoming less of maintainers and operators and more of strategic users.

3

App A

VM

Hypervisor

Server

TRADITIONAL SERVER VIRTUALIZATION

App B

VM

App A

VM

Hypervisor

Server

App B

VM

Microservice

Container

Datacenter OS

Server Server

HYPERSCALED CLOUD INFRASTRUCTURE

Server

Microservice

Container

Microservice

Container

Microservice

Container

Tradtional server virtualization vs hyperscaled cloud infrastructure

APIs: from technical need to business model driver

An application programming interface (API) is a toolset of protocols and routines expos-ing the functionality of a service or application to others, allowing them to communicate. APIs make it much simpler for developers to combine data from different sources to build applications.

APIs are far from new, but have in recent years grown significantly both in number and sophistication, as an increasing number of companies see how they can help companies innovate faster and lead to new products and new customers. This fast adoption of APIs has established a standardised format for communication, which has enabled microservices.

APIs started as an enabler for things companies wanted to do, but have today expanded from a technical need to become a business priority. They are now a critical ingredient of running a digital business and a key driver of business strategies, enabling businesses to acceler-ate new service development and offerings. The number of public APIs are exploding with businesses across industries embracing APIs and opening them up to outside developers.

APIs can expand the reach of a company’s key assets, letting them be shared, reused or resold as a new revenue stream11. From a business perspective, few software companies can today grow without publishing an API of their service. This means that developers all

9

over the world can build new, interconnected technologies and services that augment the software and take it in novel directions.

The benefits of microservicesAs organisations scale both technology and staff it becomes much more difficult to manage monolithic code bases. By decomposing applications into microservices, organisations will see benefits such as faster development cycles, improved productivity, superior scalability and supreme system availability.

“By decomposing applications into microservices, organisations will see benefits such as faster development cycles, improved productivity, superior scalability and supreme system availability.”

Ease of deployment

The traditional software development approach of releasing an application every couple of months is not fast enough for digital businesses that need to deploy new releases many times per week or even per day. Due to their high change costs, monolithic applications are not well suited for rapid release cycles. Releasing just a small change to a million-lines-code monolithic application requires that the whole application is deployed, which means these happen infrequently. As a result, changes usually build up between releases, leading to more comprehensive releases. And the longer between releases, the higher the risk that something goes wrong.

With microservices, developers can change the code in one service and deploy it separately from the other parts of the system. This allows them to faster deploy code and get new func-tionality out to customers sooner. If a problem should arise, it can swiftly be isolated to a single service so a fast rollback easily can be made. This speed of deployment with reduced risk is a main reason why organisations like Amazon and Netflix use microservices archi-tectures, ensuring they remove as many barriers as possible to get software out the door12.

Superior scalability

Enterprises that want to move fast and stay innovative in hypercompetitive markets require an architecture that can scale. The scaling demands for various components within an appli-cation normally differ13. Scaling monolithic applications is highly inefficient as the only way of doing this is often to clone the entire application, even though the various parts are not equally load intensive. As this doesn’t represent the actual demands on the system, it leads to wasted computing power and resources.

Microservices on the other hand, allow efficient selective scaling of application components and can scale up or down independently, without affecting the rest of the system. Rather than scaling up with bigger machines or more copies of the entire application, it’s possible to scale out with duplicate copies of the heaviest-used parts. Consequently, a microservices

10

architecture means more efficient use of code and underlying infrastructure, resulting in cost savings reducing the amount of infrastructure required to run a given application.

4

A microservices architecture has each piece of func�onality in a separate service

A monolithic app has all func�onality in a single process

It scales by cloning the en�re applica�on on mul�ple serversIt scales by distribu�ng services across servers, replica�ng as needed

TRADITIONAL SERVER VIRTUALIZATION SCALING WITH MICROSERVICES

Scaling monolithic applications and microservices (adapted from martinfowler.com)

Technology Diversity

Trying out new technologies always involves some risk. With a monolithic application, if developers wish to test a new programming language, database or framework, every change will affect a significant part of the entire system. Microservices allow organisations to take advantage of new technology more quickly as it’s possible to embrace different technolo-gies; mixing multiple languages, development frameworks and data-storage technologies (polyglot).

As the system consists of multiple, collaborating services that communicate across lan-guage-agnostic protocols, an application can consist of microservices running on distinctive platforms (Java, Ruby, Node, Go etc.), thereby taking advantage of the specific advantages of each platform14. This means organisations can use different technologies inside each one and pick the right tool for each job, rather than having to select a standardised one-size-fits-all approach. This said, some organisations still choose to place constraints on language choices. Netflix and Twitter, for example, mostly use the Java Virtual Machine as a platform because they know the reliability and performance of that system15.

Moreover, developers have many places where they can try out a new piece of technology. They can pick a service that is lower risk and use the technology there, to limit potential negative impact.

Resilience

When a monolithic application fails, everything stops working. But since microservices are autonomous, there is much less risk that they cause a system failure if they break down16. Loose coupling with other services together with bounded context, limits its failure domain, making the system more resilient to disruptions. The failure of a single instance of a micro-service has minimal impact on the application. And if all instances of a microservice should go down, it won’t cause the entire application to crash but only impacts the function of this

11

particular microservice, so users can continue to use the rest of the application. Apart from a more stable system, increased resilience also facilitates experimentation and innovation as it makes failing less risky.

“When a monolithic application fails, everything stops working. But since microservices are autonomous, there is much less risk that they cause a system failure if they break down.”

Organisational agility

Almost every IT organisation with legacy is experiencing the problems associated with large teams and codebases. The problems are often exacerbated when the team is distributed. With conventional application architecture and monolithic code, one large team of engi-neers works on one big piece of code and are grouped according to technical expertise. They often step on each other’s feet and the speed of development slows exponentially with the growth of the code in the monolith.

With microservices architecture, applications are built by small, decentralised and autono-mous development teams. Every team is trusted to make their own decisions about the soft-ware they produce and is dedicated to a single service that can be updated independently. This encourages ownership of particular functions and makes changes both easier and faster as there are fewer bottlenecks and less resistance to change so decisions can be made quicker.

Moreover, small teams working on small codebases have a better overview of the code, which makes it easier for new developers to understand the functionality of a service. And because each piece of the application is independent of the rest of the stack, programmers don’t have to understand how everything else works so there is no need for lengthy integra-tion work across development teams.

5

Developers Monolith Delivery pipeline

MONOLITH DEVELOPMENT LIFECYCLE

Build Test Deploy

Developers Microservices Delivery pipelines

MICROSERVICE DEVELOPMENT LIFECYCLE

Build Test Deploy

Build Test Deploy

Build Test Deploy

Build Test Deploy

Monolith vs Microservice development lifecycle

12

Replaceability

The barriers to replacing a microservice or removing it are very low as the codebase seldom is longer than a few hundred lines and the team managing the service has a good under-standing of the code.

Reusability

As businesses shift from thinking in terms of narrow channels to holistic concepts of cus-tomer engagement, they have to consider the multitude of ways they want to integrate capa-bilities for the web and native applications on desktop, mobile and wearables—and they need the right architectures for this. Microservices open opportunities for functionality to be reused and consumed in different ways for different purposes, which is important with regard to how consumers use the software. Each microservice acts like a Lego block that can be plugged into an application stack so organisations can assemble them to build applications catering to a variety of use cases. And as circumstances change, it’s possible to rebuild things in new ways.

Challenges with microservicesWhile microservices provide many benefits, they also come with costs. Microservices is no silver bullet and they have all the associated complexities of distributed systems. While the services themselves are simple, there is a great deal of complexity at a higher level with regard to managing these services and orchestrating business processes17. Every organisa-tion and system is different and a number of factors will determine whether or not micros-ervices are right for yours. However, with the right automation and tools, most drawbacks can be addressed.

Distribution

A microservices architecture necessitates a distributed system which can be complex and hard to manage. Services interact using an inter-process communication mechanism18. Remote calls are slow and can fail at any moment why developers should design for failure19. So as not to lose performance, most microservice systems use asynchronous communica-tion, which is difficult to get right, and is harder to debug20. Also, with more components exchanging information, it leads to increased network communication and risk for network congestion, reinforcing the need for reliable and fast network connections.

Operational complexity

Microservices introduce additional operational complexity as there are many more moving parts that have to be managed and monitored. You have a multitude of individual services to build, test, deploy and run, possibly in polyglot languages and environments21. This over-head will increase exponentially as you add more microservices to your application.

While monitoring each individual service instance is easier (because they are doing less), the cost to monitor the entire application is higher and it’s difficult to debug behaviour that spans many services22. Well defined service boundaries will improve this issue, while ill-chosen boundaries will make it worse.

13

Testing within each service is straightforward as the test surface is smaller and developers can test services locally, but testing the entire application as a whole and how services func-tion with one another can be complicated.

Substantial DevOps Skills Required

Handling the complexity involved in maintaining a microservices based application with lots of services that continuously are being redeployed requires many new skills and tools. It reinforces the necessity of using Continuous Delivery and DevOps. Without the automation and collaboration that Continuous Delivery promotes, controlling a swarm of services is simply not possible23. You’ll also need a DevOps culture24 with deep collaboration between developers, operations and all others involved in software delivery. Experienced DevOps teams with a high level of expertise that can keep the microservices up and available are hard to find.

“Without the automation and collaboration that Continuous Delivery promotes, controlling a swarm of services is simply not possible.”

Eventual Consistency

Microservices introduce eventual consistency issues due to decentralised data management. As microservices entails updating multiple resources, developers need to be aware of this and work out how to identify when things become out of sync. Business logic risk acting on inconsistent information, and when this occurs it can be difficult to identify where the problem is as the inconsistency window will have closed by the time you try to diagnose the issue25.

API mismatch

Services rely on the interfaces between them to communicate and for this to work flawlessly, messages must have a format and semantics that every interface can read26. As all services are interrelated, modifying one service’s interface can introduce errors such as message format differences between API versions. To avoid this, you need to adjust all the other interfaces as well so other services can understand that change. This requires many changes that need to be released in a coordinated fashion, although some changes can be avoided with backwards compatibility approaches.

Security

Security has been named one of the biggest barriers to container adoption27 and cloud-hosted microservices present new security challenges28 that must be addressed to avoid vulnerabilities, including:

• More attack surfaces: With more moving parts, there are more potential vulnerabilities to exploit for attackers.

14

• Less internal consistency: Microservices allow developers to shift programming lan-guages and frameworks. However, any time something changes, new vulnerabilities may appear.

• Existing tools don’t address securing microservices: Most existing security tools were created before microservices made their way to the enterprise. New alternatives are emerging, but off-the-shelf security tools are still limited, which means companies have to be particularly careful when securing their microservices based applications.

• New trust relationships: With containerised infrastructure, you can easily download and deploy container images from public repositories at no cost. However, this means you’re incorporating third-party software into your stack and you can never guarantee the security of code that you’re not in control of.

These challenges mean architects have to rethink how to secure applications. But with the proper strategies29, security risks can be mitigated:

• Secure the internal environment: Make sure your hosting environment is as secure as it can be. For a Docker cloud environment, this implies limiting access to the cloud host and configuring Docker to prevent public internet connections except where needed.

• Use security scanners: Tools such as Docker Security Scanning helps finding and fixing security vulnerabilities inside containers.

• Use access control: Apply access-control limitations at multiple levels of the software stack to mitigate security risks.

• Assure communication: Make sure everyone involved in building and deploying soft-ware doesn’t operate in silos but communicate continuously so they’re aware of poten-tial security implications with changes.

As more and more enterprises start using microservices, security will eventually get easier to manage. Microservices can actually also improve security through isolation between appli-cation components—mitigating the risk that a breach in one component enables attackers to compromise the whole stack. They also provide resilience against DDoS attacks as con-tainers allow superior flexibility and scalability.

Should your business use microservices?While many teams have found microservices to be a superior approach, others have found them to be a burden that reduce productivity. Like any architectural style, microservices have both advantages and downsides. To make a correct decision and determine if micro-services is right for them, companies have to understand the trade-offs and apply them to their specific context. Not every application is complicated enough to warrant being broken into microservices and in many use cases the complexity of microservices may hamper the team’s productivity.

“Not every application is complicated enough to warrant being broken into microservices.”

15

The microservices premium30 is the cost organisations pay in reduced productivity to learn and manage microservices, and this cost will only be justified for complex applications. As a software system increases in complexity, the premium is outweighed by the fact that microservices alleviate the productivity loss caused by mounting complexity.

There comes a point when an application becomes complex enough or the number of engi-neers working on it grows past 50-75 that the benefits of a microservices architecture begin to take off31. Adopters like GE, Goldman Sachs and Airbnb say it’s been well worth the tradeoff and that the benefits far outweigh the costs. As more organisations adopt the micro-services model, improved tools will also emerge to manage the increasing complexity.

6

THE MICROSERVICES PREMIUM

For less complex systems, the added effort required to manage microservices reduces productivity

As complexity rises, productivity falls rapidly with monolithic applications

The benefits of microservices outweighs the added effort to manage microservices

Prod

uctiv

ity

Base Complexity

Microservices

Monolith

NB: The level of team skills is more important than any monolith/microservices consideration

The microservices premium (Image adapted from martinfowler.com)

Adopting microservicesIt can be dispiriting for DevOps advocates observing companies like Spotify and Sound-Cloud that successfully have adopted microservices and want to implement them in their own enterprise setting. If you’re not a startup or a born digital company, you won’t be designing a microservice based system from scratch and likely have a legacy of culture, organisation, processes, tools, services and architecture standing in the way. Applications are likely too tightly coupled to the rest of the architecture to be independently developed, deployed and qualified32.

Embracing microservices requires significant planning, discipline and coordination with new toolsets and a change in team dynamics that will affect all aspects of the organisation. To execute successfully, the approach requires considerable organisational and cultural adjustment.

Before you take a microservices system into production, you need to make sure you have certain key prerequisites in place. If your organisation doesn’t have these capabilities, you need to obtain them before you put a microservice application into production. The capa-bilities are highly relevant for monolithic systems too. In fact, one can argue that DevOps, Continuous Delivery and automation are more important than microservices.

16

Prerequisites

Rapid Provisioning: You need the capability to spin up a new server in a few hours33. This fits in with cloud computing, but can be accomplished without a complete cloud service. Rapid provisioning requires automation. Being able to automate your systems and push code updates regularly are critical to deal with the complexity you will incur with micros-ervices architecture.

Monitoring: With many loosely-coupled services working together in production, things will inevitably break in ways that are hard to notice in test environments34. Microservices require a far more comprehensive monitoring effort to uncover problems quickly than mon-oliths do. If an unexpected problem appears, you need to ensure you can quickly rollback. The microservices monitoring landscape is currently fragmented; there is no clear winner and some companies are building their own products.

Rapid deployment: With many services to manage, you have to be able to deploy them quickly—both to test environments and to production. This will typically comprise a deploy-ment pipeline that can execute in a few hours at maximum35. The objective should be to fully automate it, although some manual intervention will probably be required at the first stage.

DevOps and Continuous Delivery: DevOps is a key enabler for microservices and pro-vides the framework for developing, deploying, and managing the container ecosystem. Close collaboration between developers and operations is a must to make sure that pro-visioning and deployment can be done quickly36. It’s also important to make sure you can respond quickly when monitoring signals an issue. Any incident management has to involve the development team and operations—both in resolving the immediate problem and the root-cause analysis to make sure the underlying issues are fixed.

Culture: There is need for strong organisational support and an overall shift in the IT cul-ture to succeed with microservices. Organisations have to increase their tolerance for risk and learn to fail gracefully, fast and often to achieve success. The culture must also embrace automation of deployment and testing. For developers, operations and testing engineers with long experience in monoliths, a microservices-based system is a new reality and they will need time to manage this shift.

Organisation: The most challenging aspects of moving from a monolith to microservices are the organisational changes required, such as building services teams that own all aspects of their microservices. Small, agile teams who can integrate their work frequently are an important precursor to microservices. A cornerstone involves promoting collective code ownership and fostering software craftsmanship.

You also need to shift towards product centred teams, and organising your development environment so developers can effortlessly switch between multiple repositories, libraries and languages.

Governance: As microservices involve a variety of technologies and platforms, centralised governance isn’t optimal. The microservices community favours decentralised governance as its developers strive to produce useful tools that can then be used by others to solve the

17

same problems37. Netflix, for example, encourages developers to save time by using code libraries established by others.

However, you must design and manage your evolution to microservices, or the result will be an uncontrollable sprawl. It’s key to have a cross-functional team in charge of the develop-ment, maintenance and operation of microservices that’s distinct from those managing the monolithic application38. This team should understand how the components fit together, control architectural decisions, guide the creation of new services and ensure standards adoption. To avoid creating duplicates of services, create a shared repository of all services for teams to use in development.

Microservice architecture also favours decentralised data management. Monolithic systems use one logical database across different applications. But in a microservice application, every service normally manages its own database.

Security: More surfaces and complexity raise security requirements39. You need to think about how you’ll authenticate who can speak to whom and identify illicit traffic. It also involves taking decisions on who has authority to work on certain services, if all services are to be used for all tasks in the organisation, and how shared services will be billed and managed.

Moving from monolith to microservices

With the above foundational capabilities in place, your organisation is ready for a first sys-tem using a handful of microservices.

1. Before splitting out services, it’s key that you understand your system’s domain and what it does, to be able to identify proper bounded contexts for services. Getting service boundaries wrong can result in having to make costly changes in service-to-service col-laboration later on40.

2. Begin by identifying non-critical functionality in the monolithic application that is rather loosely coupled with the rest of the system. Take one piece at a time and break it off. Once the piece is working, move to the next. A more forceful approach can lead to lost functionality and make it hard to diagnose problems. Another option is to dictate that all new functionality is built as microservices.

3. Move gradually to develop an understanding of your organisation’s ability to change. Allow the new paradigm to settle and give the organisation time to grow new capabili-ties, build the tooling and processes necessary to manage microservices well, learn about keeping the new system healthy and ensuring the DevOps collaboration is working well before you ramp up your number of services.

4. Begin with some coarse-grained but self-contained services41. You can fine-grain the ser-vices as the implementation progresses. Coarse-grained services result in fewer network calls between the monolith and the microservices.

5. Minimise changes being made to the monolith for supporting the transition in order to lower maintenance cost and reducing the impact of the migration.

6. The monolithic application must be adapted to support feature toggling—enabling you to switch between using the new service and the code in the monolithic application.

18

You need to have a fallback and prepare for a smooth load transfer to the new service. Iteratively deprecate similar functionalities in the monolith.

7. To reduce the development and operational costs of the migration, the patterns employed by the microservices should be appropriate to the monolith’s architecture.

8. A major challenge is to design and develop the integration between the current system and the new microservices42. When part of the application is redesigned with microser-vices, it’s common to write glue code to support communication with the new services. An API gateway can combine several individual service calls into one coarse-grained service, to reduce the cost of integrating with the monolithic system.

9. The new microservices should be self-contained with their own runtime environment. The services should also be deployed on infrastructure that is physically or logically isolated from the monolith.

10. Create standardised service templates that form boilerplates for development and con-tain common elements required to support the microservices-based application, such as monitoring, log collection, metrics and safety mechanisms43. The boilerplate should account for polyglot technologies comprising application servers, database, program-ming language etc. This will lower the ramp up time for development teams and create standardisation for Operations.

11. Going further than a handful of services will require more effort, including tracing business transactions through multiple services and automating your provisioning and deployment by completely adopting Continuous Delivery.

When is the microservice transformation done?

Creating and maintaining an information system is never done and this is also valid for sys-tems built with microservices. Architects and developers can sometimes spend a lot of time attempting to identify the “ideal” solution or implementation model for their system design, which rarely works44. One advantage of microservices is that change over time isn’t as costly or risky as it might be in tightly coupled large-scope release models. Perfecting the system is unviable as it will always be a moving target, and the moment you reach a final state you’ll start to accumulate technical debt—progressing towards an outdated system that will be dif-ficult to change. Working according to the microservices model implies many small releases over time and you’ll continuously be changing and improving something. This means there will be many milestones along the way that together add up to major changes over time.

Greenfield Projects

For greenfield development, Martin Fowler45 and Sam Newman46 generally recommends starting new products as monoliths and once you have a sense for how the product will be used, you can decompose from there. This is because it’s hard to know how best to divide up a monolith until its usage has been observed and it’s easier to chunk up something you already have. However, some disagrees47 with this approach, while stressing that it’s abso-lutely key to know the domain very well before starting.

19

Tools

This article will not go into the technical implementation details of microservices. However, Matt Miller at Sequoia Capital has produced an excellent map of the Microservices Ecosys-tem48, containing both commercial and open source projects important to microservices today. Toolsets that need to be added to the stack includes orchestration, monitoring, secu-rity, inter-service communications, API Management etc. The most straightforward way to get started is with Docker49, which is an attractive platform for both startups and enter-prises due to the available number of tools and the ecosystem around it. You can register for a hosted container service such as Google Container Engine or Amazon EC2 Container Service to obtain a sense of what it’s like to deploy and manage containerised applications.

About the authorsJesper Nordström is Head of Insights at 3gamma and also leads the firm's digital acceler-ation practice. With a cross-disciplinary background, he has extensive experience working at the intersection between business, IT and design – helping companies gain competitive edge by leveraging digital technologies. Areas of expertise include digital transformation, innovation strategy and emerging technologies. Jesper holds dual degrees in engineering and business management.

Tomas Betzholtz is an IT Management consultant within the Emerging Technology capa-bility at 3gamma. He has over 20 years of experience from the IT industry focusing on IT architecture and transformation. He has experience from a varying set of companies, from manufacturing to finance and insurance where he has helped IT organisations improve their architectural skills to enable business efficiency.

20

References1. https://techcrunch.com/2016/01/23/get-small-to-get-big-through-microservices/

2. https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture

3. https://medium.freecodecamp.com/an-introduction-to-microservices-2705e7758f9#

4. http://www.nirmata.com/2015/02/microservices-five-architectural-constraints/

5. https://en.wikipedia.org/wiki/Conway%27s_law

6. http://blogs.wsj.com/cio/2015/10/05/innovate-or-die-the-rise-of-microservices/

7. http://www.cio.com/article/2924995/enterprise-software/what-are-containers-and-why-do-you-need-them.html

8. http://www.infoworld.com/article/2906362/data-center/dawn-of-the-data-center-operating-system.html

9. http://a16z.com/2015/04/08/aggregation-is-the-new-virtualization-how-microservices-are-taming-distributed-comput-ing/

10. http://www.infoworld.com/article/2906362/data-center/dawn-of-the-data-center-operating-system.html

11. http://dupress.com/articles/tech-trends-2015-what-is-api-economy/

12. http://samnewman.io/books/building_microservices/




16. http://martinfowler.com/articles/microservice-trade-offs.html

17. http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

18. https://www.nginx.com/blog/building-microservices-inter-process-communication/

19. http://martinfowler.com/articles/microservices.html#DesignForFailure

20. http://blog.xebia.com/microservices-architecture-principle-4-asynchronous-communication-over-synchronous-communi-cation/







27. http://www.infoworld.com/article/3029772/cloud-computing/how-to-secure-containers-and-microservices.html

28. http://searchcloudapplications.techtarget.com/tip/Everything-you-need-to-know-about-securing-microservices

29. http://searchcloudapplications.techtarget.com/tip/Everything-you-need-to-know-about-securing-microservices

30. http://martinfowler.com/bliki/MicroservicePremium.html

31. https://techcrunch.com/2016/01/23/get-small-to-get-big-through-microservices/

32. https://devops.com/2015/03/03/avoiding-common-executive-devops-mistakes/

33. http://martinfowler.com/bliki/MicroservicePrerequisites.html




37. https://smartbear.com/learn/api-design/what-are-microservices/

38. http://thenewstack.io/microservices-four-essential-checklists-getting-started/

39. https://techcrunch.com/2016/01/23/get-small-to-get-big-through-microservices/


21


42. http://thenewstack.io/from-monolith-to-microservices/


44. http://transform.ca.com/API-microservice-architecture-oreilly-book.html

45. http://martinfowler.com/bliki/MonolithFirst.html

46. http://samnewman.io/blog/2015/04/07/microservices-for-greenfield/

47. http://martinfowler.com/articles/dont-start-monolith.html

48. https://www.sequoiacap.com/article/build-us-microservices/

49. http://searchvirtualdesktop.techtarget.com/opinion/What-is-Docker-and-what-does-it-mean-for-virtualization

50. https://blog.risingstack.com/how-enterprises-benefit-from-microservices-architectures/

51. http://www.mckinsey.com/business-functions/business-technology/our-insights/beyond-agile-reorganizing-it-for-fast-er-software-delivery

24

ABOUT 3GAMMA

3gamma provides independent technology strategy consulting and IT advisory services to industry leading companies across sectors. Operating from offices in Sweden, UK and Denmark, we work closely with senior executives, strategists and technologists to accelerate growth and seize the opportunities of the digital age.

Through our six capabilities we help clients realise the maximum value of their technology investments and ensure that their technology operations are agile, effective and support innovation:

• Strategy & Governance

• Emerging Technologies

• Sourcing & Legal

• Risk & Assurance

• Operational Excellence

• Transformation & Change

3gamma Insights brings leading-edge thinking at the intersection of IT and business, illuminating central topics relevant to CIOs and decision makers.

STOCKHOLM3gamma Sweden ABCentralplan 15SE-111 20 StockholmSwedenPhone: +46 8 748 0330

GOTHENBURG3gamma Sweden ABDrottningtorget 5SE-411 03 GöteborgSwedenPhone: +46 31 309 7910

DENMARK3gamma ApSFrederiksborggade 15DK-1360 Copenhagen KPhone: +45 53 700 400

MALMOEAdelgatan 21 SE-211 22 MalmöSwedenPhone : +46 40 630 4610

UNITED KINGDOMThe News Building 3 London Bridge StreetLondon SE1 9SGUnited KingdomPhone +44 (0) 203 743 6104