Everything old is new again: Microservices

old-building-with-modern-addition

If I told you about a software architecture in which components of an application provided services to other components via a communications protocol over a network you would say it was…

Well, it depends. If you got your start programming in the 90s, you’d say I just defined a Service-Oriented Architecture (SOA). But, if you’re younger and cut your developer teeth on the cloud, you’d say: “Oh, you’re talking about microservices.”

You’d both be right. To really understand the differences, you need to dive deeper into these architectures.

In SOA, a service is a function, which is well-defined, self-contained, and doesn’t depend on the context or state of other services. There are two kinds of services. A service consumer, which requests a service from the other type, a service provider. An SOA service can play both roles.

SOA services can trade data with each other. Two or more services can also coordinate with each other. These services carry out basic jobs such as creating a user account, providing login functionality, or validating a payment.

SOA isn’t so much about modularizing an application as it is about composing an application by integrating distributed, separately-maintained and deployed components. These components run on servers.

Early versions of SOA used object-oriented protocols to communicate with each other. For example, Microsoft’s Distributed Component Object Model (DCOM) and Object Request Brokers (ORBs) use the Common Object Request Broker Architecture (CORBA) specification.

Later versions used messaging services such as Java Message Service (JMS) or Advanced Message Queuing Protocol (AMQP). These service connections are called Enterprise Service Buses (ESB). Over these buses, data, almost always in eXtensible Markup Language (XML) format, is transmitted and received.

Microservices is an architectural style where applications are made up from loosely coupled services or modules. It lends itself to the Continuous Integration/Continuous Deployment (CI/CD) model of developing large, complex applications. An application is the sum of its modules.

Each microservice provides an application programming interface (API) endpoint. These are connected by lightweight protocols such as REpresentational State Transfer (REST), or gRPC. Data tends to be represented by JavaScript Object Notation (JSON) or Protobuf.

Both architectures stand as an alternative to the older, monolithic style of architecture where applications are built as single, autonomous units. For example, in a client-server model, a typical Linux, Apache, MySQL, PHP/Python/Perl (LAMP) server-side application would deal with HTTP requests, run sub-programs and retrieves/updates from the underlying MySQL database. These are all tied closely together. When you change anything, you must build and deploy a new version.

With SOA, you may need to change several components, but never the entire application. With microservices, though, you can make changes one service at a time. With microservices, you’re working with a true decoupled architecture.

Microservices are also lighter than SOA. While SOA services are deployed to servers and virtual machines (VMs), microservices are deployed in containers. The protocols are also lighter. This makes microservices more flexible than SOA. Hence, it works better with Agile shops.

So what does this mean? The long and short of it is that microservices are an SOA variation for container and cloud computing.

Old style SOA isn’t going away, but as we continue to move applications to containers, the microservice architecture will only grow more popular.

Comments

  1. It would be great if you could add up on service orchestration 🙂

    Like

  2. jeffreyyeah says:

    While the trend the past couple years has been to put microservices in containers, that was not the prior case for the 6 or so years microservices have been popular.

    Another distinction of microservices from SOA is that a database must be connected to by only a single service. This allows business logic close to the data to be contained. Of course microservices can be composed together to let higher level business logic play out. Having only one service writing to a DB keeps unexpected changes down, and reduces duplicate business logic.

    Like

Trackbacks

  1. […] Everything old is new again: Microservices 6 by CrankyBear | 1 comments on Hacker News. […]

    Like

  2. […] Everything old is new again: Microservices 8 by CrankyBear | 1 comments on Hacker News. […]

    Like

  3. […] Everything old is new again: Microservices 23 by CrankyBear | 13 comments on Hacker News. […]

    Like

  4. […] DXC.technology Blog – Everything old is new again: Microservices […]

    Like

  5. […] Everything old is new again: Microservices […]

    Like

  6. […] 5、[文章]Everything old is new again: Microservices(英文) […]

    Like

  7. […] 5、[文章] Everything old is new again: Microservices(英文) […]

    Like

  8. […] 5、[文章] Everything old is new again: Microservices(英文) […]

    Like

  9. […] 5、[文章] Everything old is new again: Microservices(英文) […]

    Like

  10. […] it’s best known for its use with Kubernetes to monitor containers and microservices on clouds, that’s far from Prometheus only use. For example, Uber uses Prometheus with its […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

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

Facebook photo

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

w

Connecting to %s

%d bloggers like this: