• No results found

Ifw Dd 2016 Microservices

N/A
N/A
Protected

Academic year: 2021

Share "Ifw Dd 2016 Microservices"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

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

Deep

Deep

Dive

Dive

      T       T       H       H       I       I       N       N       K       K       S       S       T       T       O       O       C       C       K       K

(2)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

2

P A A S

Why you should be

using microservices

Deep Dive

2

InfoWorld.com DEEP DIVE SERIES

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

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 onhundreds 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.

(3)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

3

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

How did eBay

overcome its

overburdened

legacy

archi-tecture? 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-million-line 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 consid-ered 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 microser-vices architecture, apps are built by small,

InfoWorld.com DEEP DIVE SERIES

3

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.

x

Microservices - Application databases Monolith - Single database

(4)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

4

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

decentralized development teams that work and change microservices independently. This makes it easier to upgrade services and add function-ality. Both the software and the development process become more agile.

For all these reasons, microservices have enjoyed increasing popularity. But every architec-ture has its strengths and weaknesses. Microser-vices 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 microser-vice 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 techni-cal 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.

U I T e a m DBAs Middleware guys Supply Orders Recommender

(5)

Deep Dive

5

InfoWorld.com DEEP DIVE SERIES

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

application in the first place? In theory, at least, you can imagine they would live in sepa-rate 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 indepen-dently comes with a whole new set of concerns — specifically around logging, monitoring, testing, and debugging your newly decentral-ized, 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.

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 architec-tures 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 data-base-level joins. This results in more database queries more often than a single SQL command might incur, but you can mitigate that by incorpo-rate caching within the microservice

layers. After all, each microservice can have its own caching technology. Over the long haul, this approach might be less elegant than a straight-forward 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 microser-vices communicate with events happening throughout the applica-tion. This architecture is the foun-dation of building truly rich and complex microservice-based applica-tions, 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 orches-tration solutions for these problems are becoming more stable and reli-able every day.

Whether you are looking at Kubernetes, Mesos, Swarm, or Fleet, these orchestration tools all basi-cally do the same thing: They let you declaratively architect your devops platform.

Traditional devops tools are

      T       H       I       N       K       S       T       O       C       K

(6)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

6

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

If there’s a bug, which microservice is respon-sible for it? The interdependencies between microservices can make that question madden-ingly 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

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

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 job-scheduling 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? 

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 signifi-cant 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

doing the Article REST API. The underlying articles data-base, 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 indepen-dently deployable whereas SOA services are often implemented in deployment monoliths.”

Microservices philosophy is fundamentally about killing applica-tion and database monoliths. It is

about creating highly distributed, autonomous, horizontally scal-able applications. The hallmarks of microservices are lightweight compo-nents 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, microser-vices 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

      T       H       I       N       K       S       T       O       C       K

(7)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

7

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

The easiest

way to think

about building

a

microservice- based

applica-tion is to start

with the front

end and work

 backward.

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 situa-tions out there. But when you architect around microservices philosophies, you gain hidden bene-fits, such as tying in with other new technologies such as PaaS, Linux containers, or Docker.

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 some-thing 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

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.

How to think about building microservices apps

If you’ve never created a microservices architec-ture 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 tradi-tional architectural practice on its head.

To illustrate this inverted approach, let’s consider a simple blogging application. Tradi-tionally, 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 consid-ering 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

(8)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

8

It’s important

to remember

that

microser-vices are a

response to

hitting a glass

ceiling.

At some point,

traditional

monolithic

application

architectures

don’t scale

anymore.

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

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 inte-grating 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 func-tionality 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 rele-vant, 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 each other. Everything in this application is decentralized. Instead of one big relational database, each microservice has its database. Each microservice can scale indepen-dently. 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 third-party services. For example, instead of building your Comment microservice, you might use Disqus. Instead of creating your own authentica-tion 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 ques-tion of whether you should be using microser-vices might surprise you. The answer is not always going to be yes. As microservices consul-tant Chris Richardson says, “It is not simple, but then again, the reason y ou are using microser-vices 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 architec-tures 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.

(9)

Deep Dive

InfoWorld.com DEEP DIVE SERIES

9

T H E E S S E N T I A L G U I D E T O M I C R O S E R V I C E S

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

some-times 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 soft-ware projects — and you don’t need to throw away all your old code 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 applica-tion from the beginning.

eBay has said that microservices architecture has enabled the company to expand to massive scale, increased code scalability and maintain-ability, 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 applica-tion, 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

References

Related documents

An analogy can be drawn between income inequality and income convergence and dynamics of prices across locations (cities, regions within a country, countries, etc.).. Interpreting

When you are ordering replacement parts, please refer to this Parts Catalogue and quote both part numbers and part names correctly.. Modifications or additions which have been

Archbishop of Paris declares Daughters of Charity depen- dent on him; delegates powers of Superior to Saint Vincent, XIIIb, 133; Saint Louise is upset by this dependence and lim-

For the primary endpoint of culture- or PCR-confirmed influenza PD-ILI caused by any influenza viral type/subtype (regardless of similarity to the vaccine), IIV-HD was significantly

We’ll look at how the cloud is shaping up in the ERP market, define how ERP vendors are approaching the cloud, identify security and cost considerations, and outline the general

An example  of this is a  medical laboratory business that had  developed new and unique  tests  and  reports  that  had  become  approved  for  payment 

working through the headquarters emergency control centre and the District Officers. The District Officers will coordinate disaster relief efforts at the local level, in

National Collegiate Athletic Association (Case No. Ill.): Appointed co-lead interim class counsel in a nationwide class action against the NCAA on behalf of current