Microservices challenges

There has been significant buzz around microservices lately, enough to generate some hype. After implementing heavy and cumbersome SOA solutions for more than a decade, are microservices the solution the industry has been waiting for? Or, are microservices simpler than monolithic solutions? Before discussing these issues, it would be a good idea to include a definition.

Recently microservices have been getting a lot of attention, both positive and negative. Articles about them tend to fall into two camps, which I'll affectionately label the hipster camp and the neckbeard camp. The hipster camp tends to strongly favor microservices, due to the excellent benefits they provide regarding ...

Undeniably, there is a growing interest in microservices as we see more organisations, big and small, evaluating and implementing this emerging approach. Despite its apparent novelty, most concepts and principles underpinning microservices are not exactly new - they are simply proven and commonsense software development practices that now need to be applied holistically and at a wider scale, rather than at the scale of a single program or machine.

Decomposing our infrastructure into a large number of small simple services, each with a single responsibility, has had a huge number of benefits. It allows us to more easily understand each component and rationalise their behaviour, allowing us to scale both our software and teams far more easily, and letting us to develop new functionality extremely quickly.

Recently there has been much buzz around the concept of "microservices." Microservices take service-oriented architecture to the next level by dividing applications into even smaller sub-units, often along lines of business capabilities . Proponents of microservices point to the ability to more readily "scale up" their application in response to demand, and ability to achieve encapsulation behind the barrier of an Application Programming Interface (API).

Tuesday, April 8, 2014 at 8:54AM This is a guest post by Benjamin Wootton, CTO of Contino, a London based consultancy specialising in applying DevOps and Continuous Delivery to software delivery projects. Microservices are a style of software architecture that involves delivering systems as a set of very small, granular, independent collaborating services.

If you want evidence that the software development industry is susceptible to fashion, just go and take a look at all of the hype around microservices. It's everywhere! For some people microservices is "the next big thing", whereas for others it's simply a lightweight evolution of the big SOAP service-oriented architectures that we saw 10 years ago "done right".

Uploaded by Agata Surgot on 2015-03-05.

Many of our clients are in the process of investigating or implementing 'microservices', and a popular question we often get asked is "what's the most common mistake you see when moving towards a microservice architecture?". We've seen plenty of good things with this architectural pattern, but we have also seen a few recurring issues and anti-patterns, which I'm keen to share here.

Bolstered by the near-meteoric rise of container technology, especially Docker, the term "microservices" is now being used to describe the type of software architecture anointed as the shiny new technology that will deliver software engineering to the Promised Land.