Ifw Dd 2016 Microservices

DeepDive

      K       C       O       T       S       K       N       I       H       T

Copyright © 2016 InfoWorld Media Group. All rights reserved. • $129

PH T AE AS ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive

Why you should be using microservices Today’s applications need to be modified, scaled, and updated constantly to meet changing business needs. Microservices enable you to manage that flux easily and reliably. BY LUCAS CARLSON

So you’re sitting on hundreds of thousands

of lines of legacy C++. Oh, who are we trying to kid? It’s millions of lines of Vectran, a short-lived Fortran variant created by IBM in the ’70s. But hey, if it ain’t broke, right? Except it is broken. Anytime someone tries to add a feature, the thing breaks. Even trying to fix bugs creates more bugs. But if you just don’t touch it, it keeps on working. The problem is that innovation demands agility and velocity. All the cool companies that never had to worry about Y2K are outpacing your clunky old legacy software. Investors are demanding the next big thing. Customers are jumping ship in droves. The good news is that you’re not alone. Believe it or not, even the cool kids have faced similar problems. Netflix, eBay, Amazon, Twitter, PayPal, and more didn’t start out with beautifully architected scalable code that was fast and agile.

2

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive

How did eBay overcome its overburdened legacy architecture? The same way PayPal, Twitter, Amazon, and Netflix did:  by killing their application monolith.

In 2006, eBay did a presentation at the SD Forum about its architecture. The company confessed to having built a monolithic 3.3-millionline C++ ISAPI DLL that compiled into a 150MB binary. eBay developers were hitting compiler limits on the number of methods per class, while being expected to add over 1,200 new features a year with 99.94 percent availability. How did eBay overcome its overburdened legacy architecture? The same way PayPal, Twitter, Amazon, and Netflix did: by killing their application monolith. They re-architected their infrastructure using microservices, a technique that breaks large applications into lightweight apps that can be scaled horizontally.

Breaking down monoliths Microservices segment functionality into separate applications that are loosely coupled by RESTful APIs. For example, eBay created different Java servlet applications that handled users, items,

accounts, feedback, transactions, and more than 70 other elements back in 2006. Each of those logical functional applications is now considered a microservice. Now eBay probably runs hundreds of microservices. Each of these microservices is self-contained. They do not share a data layer. Each one has its own database and load balanc er. Isolation is a critical component of microservices architectures; different microservices require different scaling techniques. For example, some microservices might use relational databases whereas others might employ NoSQL databases. Building applications this way increases the scalability of teams building applications. With monolithic code, you have one big team of people working on one big piece of code and stepping on each other’s feet all the time. T he speed of development slows exponentially with the growth of the code monolith. With microservices architecture, apps are built by small,

A database for every service In a conventional architecture, a single database supports one monolithic application. In microservices architecture, each service has its own database, which could be an RDBMS or a NoSQL database depending on the requirements. Together, these services and their databases deliver the user experience.

Monolith - Single database

Microservices - Application databases

x

3

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive decentralized development teams that work and change microservices independently. This makes it easier to upgrade services and add functionality. Both the software and the development process become more agile. For all these reasons, microservices have enjoyed increasing popularity. But every architecture has its strengths and weaknesses. Microservices architectures bring a whole new set of problems that are hard to tackle. In this Deep Dive, we’ll explore the pros and cons of microservices as we unpack this modern method of building applications. Then we’ll walk through how to build a microservices-based blogging application step by step to show how microservices work in the real world. Finally, we’ll

address some of the most frequent concerns about microservices and answer the biggest question: Should you be using microservices? The answer to that last question may surprise you.

The pros and cons of microservices Microservices philosophy tears down large monolithic applications with massive complex internal architectures into smaller, independently scalable applications. If you’re eBay, for example, you can imagine that the user feedback microservice would be smaller and less complex than the bidding microservice. When you think about it, why should those functionalities need to be built into a single

How microservices affect who does what Conventional application architecture groups people according to their technical expertise. Microservices architecture tends to result in multiple small teams, each dedicated to a single service that can be updated independently. This new arrangement encourages ownership over particular functions.

UI Team

Supply

Middleware guys

Orders

DBAs

Recommender

4

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive application in the first place? In theory, at least, you can imagine they would live in separate application and data silos without major problems. For example, if the average auction received two bids, but only a quarter of all sales received feedback, the bidding service would be at least eight times as active as the feedback application at any time of day.

In that way, separating different functionality groups into separate applications makes intuitive sense. Yet the benefit of being able to build and scale different parts of your application independently comes with a whole new set of concerns — specifically around logging, monitoring, testing, and debugging your newly decentralized, loosely coupled application.

FAQ: Your

 microservices questions,  answered  AS DEVELOPERS  AND MANAGERS  WADE INTO microservices, many of the same questions arise again and again. Here are some of the most common queries and their responses.

      K       C       O       T       S       K       N       I       H       T

If each service should have its own database, then how do you associate data between different databases? The first concern that people have when building microservices architectures is letting go of join tables. Once you start building applications more complicated than the simple blog example in this article, this problem becomes very apparent. The simple solution is to use application-level joins instead of database-level joins. This results in more database queries more often than a single SQL command might incur, but you can mitigate that by incorporate caching within the microservice

layers. After all, each microservice can have its own c aching technology. Over the long haul, this approach might be less elegant than a straightforward database join, but it’s certainly more scalable. A more sophisticated solution is to incorporate an event-driven, pub-sub message bus into your microservices architecture. The message bus lets various microservices communicate with events happening throughout the application. This architecture is the foundation of building truly rich and complex microservice-based applications, because you no longer need to rely on service APIs being instantly available 100 percent of the time.

 How do you orchestrate microservices? 

The operational overhead of running dozens or hundreds of smaller microservices instead of one big monolithic application might seem daunting. Without question, keeping track of all the dependencies adds complexity. Fortunately, new orchestration solutions for these problems are becoming more stable and reliable every day. Whether you are looking at Kubernetes, Mesos, Swarm, or Fleet, these orchestration tools all basically do the same thing: They let you declaratively architect your devops platform. Traditional devops tools are

5

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive If there’s a bug, which microservice is responsible for it? The interdependencies between microservices can make that question maddeningly hard to answer. Microservices communicate with each other, generally through lightweight JSON REST APIs. Unlike their predecessors XML-RPC and SOAP, REST interfaces tend to be

great at launching, managing, and monitoring individual applications, but the difference between devops tools and orchestration services is that orchestration services are built to manage complex microservice environments with dependencies between running services. At their foundation, all the orchestration tools are just jobscheduling message buses. If you are already using a message bus in your architecture, you may want to build your orchestration engine on top of your message bus.  How do you decompose existing applications? 

      K       C       O       T       S       K       N       I       H       T

You may not have the luxury of rebuilding your application using microservices architecture from the ground up. The great thing is that you don’t need to. If you are sitting on a significant legacy application and want to dip your toes into breaking it into microservices, you can start by building faux microservices. A faux microservice is the same as a regular microservice except the data store isn’t isolated from other parts of the application yet. For example, if you have a complex custom blogging application, you could create a faux Article microservice that is a separate application whose only responsibility is

more loosely defined. These lighter-weight APIs are more flexible and easier to extend, but also add a new interface that needs monitoring, may break, or causes bugs. In the old days with monolithic applications, you could add debugging hooks within the code and logically step through every execution layer

doing the Article REST API. The underlying articles database, however, is still in the same big relational database model. That way the data is not duplicated. Eventually, when enough of the faux microservices are built out, you can work on segmenting the data stores into separate silos.  Aren’t microservices just SOA (service-oriented architecture) ?

Microservices are kissing cousins to SOA, but there are significant differences. On the surface, SOA is associated with SOAP and XML-RPC whereas microservices are associated with JSON. But in some ways the API format is rather cosmetic. Likewise, SOA uses enterprise service buses and microservices use more lightweight pub-sub service busses. Again, the principle is similar, though lighter weight. Bob Rhubart might have put it most eloquently when he said that “microservices must be independently deployable whereas SOA services are often implemented in deployment monoliths.” Microservices philosophy is fundamentally about killing application and database monoliths. It is

about creating highly distributed, autonomous, horizontally scalable applications. The hallmarks of microservices are lightweight components and independent deployability. Lightweight APIs. Lightweight service bus. Lightweight data storage. What about background processes? 

Long-running background processes are becoming more and more common with the rise of big data analytics. Fortunately, microservices are well suited for this kind of problem. If you have already incorporated a pub-sub message bus into your application architecture, background processes are just another microservice without the need for a port binding. They can attach themselves by subscribing to the message bus and wait until an event is triggered. n

6

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive to discover the problem areas. When you are dealing with a mesh of dozens or even hundreds of separate applications talking to each other with loosely defined APIs, you lose that luxury. Nonetheless, with careful planning you can overcome these difficulties. At the present moment, you have relatively few off-the-shelf microservices debugging tools to choose from. You will probably have to stitch together your own solutions based on other, partial situations out there. But when you architect around microservices philosophies, you gain hidden benefits, such as tying in with other new technologies such as PaaS, Linux containers, or Docker.

The easiest way to think about building a microservice based application is to start with the front end and work  backward.

unless you commit the change. The horizontal scaling philosophy of microservices architecture promotes the concept of share-nothing, stateless applications. That is, they do not store or modify the underlying file system. You can see why people conflate microservices with Linux containers: Both retain their state. Microservices offer a sound approach to application development, as long as you are aware of the problems and shortcomings. It’s not  just another tech trend that will go away next season. It’s the way many of the biggest nam es in technology have tackled the problems of large-scale growth during the past 10 years.

Microservices, containers, and PaaS There’s a common misconception floating around right now that to use microservices you need to use PaaS or Linux containers or something similar. It’s simply not true. You can use PaaS and Linux containers without microservices, and you can use microservices without PaaS or Linux containers. Neither requires the other. But in many ways, they do complement each other well. PaaS environments optimize for running many smaller applications, whether public clouds such as Heroku or private clouds such as Cloud Foundry or OpenShift. Porting a 3.3-million-line C++ application to a PaaS platform will never happen. If you deconstruct your application into smaller, bite-sized applications that a re each self-contained and scale independently, those bite-sized applications often end up being good candidates for a PaaS environment. For that reason, thinking about adopting microservices architectures can help accelerate adoption of other technologies that might already be on your road map. Likewise, Linux containers are better suited for small, stateless applications than large monolithic ones. After all, one of the biggest and most obvious differences between a virtual machine and a Linux container is the lack of state. Virtual machines can be configured to keep their state, whereas the architecture of Linux containers intrinsically throws out any differences from the base image. With Linux containers, you can mount stateful folders in them, but the container itself won’t change

How to think about building microservices apps If you’ve never created a microservices architecture before, it takes a different way of thinking. Many developers start application design by starting with the database layout. They create a whole slew of tables, including complicated join tables. Then the application logic is built on top of the database. Finally, the user experience is put on top of the application logic. Like a three-layer cake, this approach to building applications can work well at first. The problem with this architecture is that as features are added to the application, new tables and join tables are added to the database. Then new functionality is grafted to existing code. Over time, this becomes a huge rats’ nest. The easiest way to think about building a microservice-based application is to start with the front end and work backward. Turn traditional architectural practice on its head. To illustrate this inverted approach, let’s consider a simple blogging application. Traditionally, you might start building a blog app by creating one database with an articles table, a comments table, an authors table, etc. An article might have various writers, so you may want to create a join table for articles and authors. With microservices, you might start out by taking the blog’s homepage mockup and considering the elements within it. Comments are not on the homepage of a blog, so there’s no need to find them at this point. You don’t even need

7

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive

It’s important to remember that microservices are a response to hitting a glass ceiling. At some point, traditional monolithic application architectures don’t scale anymore.

to build a comments database yet. That can happen later. First, you could create a self-contained REST API microservice called Article. The front-end mockup could become functional code by integrating a JavaScript client such as Backbone, Angular, or Ember. All three of these JavaScript clients natively work with any REST API and can pull data into a design that was previously just a mockup. The Article REST API microservice would be a lightweight application that focuses on the core functionality of storing and retrieving article data. In this stage of the microservice application development, you don’t need to worry about authentication or security models. Additional microservices can be layered in later. Don’t overburden any microservice with more functionality than necessary — hence the “micro” in microservice. One of the important things to point out at this stage is that since each microservice has a very limited scope of functionality, you end up having a lot more flexibility for the data storage options. Without large, complicated database designs, relational databases become less relevant, and NoSQL databases such as MongoDB, Couchbase, Cassandra, Redis, Riak, and others might end up working better. In theory each microservice could use a different underlying data storage mechanism that is best suited for that microservice. Once you have built your Article REST API and it’s serving dynamic data to the front-end client, you might want to tackle comments. You can build a new self-contained Comment REST API microservice that incorporates spam filters and identity technology unique to commenting. The Comment microservice fully encapsulates all the fancy commenting code. Your front-end client can now pull dynamic data from this new API as necessary. Finally, you might think about building an Author microservice that handles authentication and permission for creating new articles. The author service would presumably have a control panel front-end. It would let blog authors log in and write new blog posts. The microservice can then be integrated into both the front-end

client and the Article microservice itself. The Article microservice could make an API call to the Author microservice during the article creation process to ensure that the author has permission to write new blog posts. In the past, permissions-checking might have been done through a join table in a relational database. The lightweight interservice API calls can sometimes replace the join tables. The front-end microservices application now pulls from three separate microservices, two of which also talk to e ach other. Everything in this application is decentralized. Instead of one big relational database, each microservice has its database. Each microservice can scale independently. You might set up a load balancer with dozens of application servers for the Article microservice, but need only one instance of the Author microservice with no load balancer. Finally, this decentralized, loose coupling philosophy lends itself well to leveraging thirdparty services. For example, instead of building your Comment microservice, you might use Disqus. Instead of creating your own authentication microservice, you might employ Janrain. This approach to building application architectures might seem strange at first. But microservices architecture has proven itself as a viable alternative to the old monolithic beasts. If you decide to go down this path, you will be standing on the shoulders of giants.

Should you be using microservices? Earlier I suggested that the answer to the question of whether you should be using microservices might surprise you. The answer is not always going to be yes. As microservices consultant Chris Richardson says, “It is not simple, but then again, the reason y ou are using microservices is to tackle complexity.” It’s important to remember that microservices are a response to hitting a glass ceiling. At some point, traditional monolithic application architectures don’t scale anymore. This happens to every successful software project. Either the database grows too large, or there are too many millions of lines of code, or you simply can’t add features quickly enough anymore. If you have not hit a glass ceiling yet — that

8

THE ESSENTIAL GUIDE TO MICROSERVICES

InfoWorld.com DEEP DIVE SERIES

Deep Dive is, if your legacy application is still working well and doesn’t need to be changed much — then adopting microservices for their own sake will gain you very little other than headaches. After all, microservices bring quirks and difficulties to the development process. Keeping all these new services running can sometimes feel like juggling a dozen balls in the air. Adopting declarative orchestration tools such as Kubernetes can take some adjustment as well. Complex microservices architectures have their own lexicon to cover all the new software patterns you will need to adopt. Yet microservices aren’t nearly as daunting as SOA used to be. In fact, microservices practices can be implemented in even the smallest software projects — and you don’t need to throw away all your old c ode to get started. You can start by building faux microservices. If you have a large application that is getting out of hand, with software lifecycles that

take too long and a pace of innovation that has ground to a standstill, then microservices might be just the thing you need. Alternatively, if you are just starting out, it would be smart to consider building a microservices-based application from the beginning. eBay has said that microservices architecture has enabled the company to expand to massive scale, increased code scalability and maintainability, spurred rapid business innovation, created faster product delivery, and even enhanced security. Google, Amazon, Twitter, PayPal, and Netflix have all had similar experiences. Many of these companies have also created tools to make adopting microservices easier. Whether you are currently suffering from the problems of maintaining legacy code and don’t know how to move forward, or you are starting out with a brand-new greenfield application, now would be a good time to evaluate a microservices approach to application development. n

…now would be a good time to evaluate a microservices approach to application development

9