Microservices architecture this year more organizations will realize the benefits.
The idea of building applications using services has always had
appeal. Why code from scratch when you can assemble multiple
applications that tap the same services via standard APIs? As long as
those services are properly provisioned, you should be able to enjoy
tremendous economies of scale.
In the past, attempts at implementing this notion collapsed under the weight of over engineering (particularly the CORBA and SOA trends). But one of the most interesting aspects of micro services -- basically small, API-accessible, single-purpose programs -- is that their use has been a grassroots, developer-driven phenomenon. This time, the services approach has legs.
For a great example of micro services architecture in action, check out this 2014 blog post by Stefan Borsje, CTO and co-founder of Karma, which sells WI-Fi hotspot devices to consumers. According to Borsje, his dev team "backed into" micro services as it developed its online store:
For Karma, the biggest problem with microservices has been testing. As Borsje puts it, "Actions and eventual results are so far from another that it's difficult to see exact cause and effect. A problem might bubble up from a chain, but where in the chain did it go wrong?"
Martin Fowler, the legendary co-author of the agile manifesto who wrote everyone's favorite explanation of microservices last March, followed up in November with a presentation that outlined a multilayered approach to microservices testing in considerable detail. Not surprising, he advocates unit testing of individual services, but acknowledges this is inadequate to determine whether the entire system is functioning properly. He helpfully lays out a series of integration, component, contract, and end-to-end testing strategies that should help developers wrap their heads around one of microservices' toughest problems.
Another problem: You can't always predict which micro services may, under certain circumstances, be overwhelmed by demand. I'm sure that's one reason Karma deployed its e-commerce platforming on AWS (Amazon Web Services), where auto scaling can help ensure no service becomes a bottleneck by adding horsepower where needed. Note that the micro services poster child, Netfilx, also uses AWS -- in other words, micro services and the cloud go hand in hand. Theoretically you could build your own auto scaling private cloud using VMware or Open Stack, but the difficulty of doing that is one reason the public cloud is winning.
Another more recent technology underlying microservices is
Docker, a technology for packaging applications and deploying them in
Linux containers. As is turns out, microservices and Docker are a
perfect fit -- which is one reason why all the major public clouds now
support Docker.
Obviously, no one is saying microservices can solve every problem. But microservices architecture may succeed where other service-based approaches have failed, because it's coming from the bottom up. Developers determine the types of services and their granularity, and as the trend spreads to larger enterprises teams can decide which services are best of breed for the whole organization.
That sort of ad hoc build-out would have been impossible with the hardwired infrastructure of the past. Equally as important, developers have grown a lot better at collaborating, with a shift in culture that lends itself to creating software architecture organically rather than following edicts passed down from on high.
From what I'm hearing, in many organizations developers are already employing micro services architecture whether management knows it or not. With the right cloud infrastructure, either public or private, micro services architecture can not only boost developer productivity, but also enable the development of new applications that would have been impractical to build before.
Read More:- Techies | Update
In the past, attempts at implementing this notion collapsed under the weight of over engineering (particularly the CORBA and SOA trends). But one of the most interesting aspects of micro services -- basically small, API-accessible, single-purpose programs -- is that their use has been a grassroots, developer-driven phenomenon. This time, the services approach has legs.
For a great example of micro services architecture in action, check out this 2014 blog post by Stefan Borsje, CTO and co-founder of Karma, which sells WI-Fi hotspot devices to consumers. According to Borsje, his dev team "backed into" micro services as it developed its online store:
We started out with one big app in the back end and we split off pieces when it made sense. ... By just going ahead and building the app, we became familiar with the problem we were trying to solve, and the more familiar we were with the problem, the more obvious it was where we needed boundaries between aspects of the app. Every time we encountered something that clearly looked like it should be a separate piece, we turned it into a service.
At first, these pieces were relatively large, but as with other stories of micro services adoption, we've discovered those pieces can be smaller and smaller.For example, the monolithic app originally had a "store" component, which Borsje's team broke down into order processing, fulfillment, and tracking services. Even the public-facing front end has been split apart into services. Isolating granular functions into independent services has resulted in a major productivity boost, says Borsje, in part because developers don't need to keep all the dependencies of a monolithic application in their heads as they work.
For Karma, the biggest problem with microservices has been testing. As Borsje puts it, "Actions and eventual results are so far from another that it's difficult to see exact cause and effect. A problem might bubble up from a chain, but where in the chain did it go wrong?"
Martin Fowler, the legendary co-author of the agile manifesto who wrote everyone's favorite explanation of microservices last March, followed up in November with a presentation that outlined a multilayered approach to microservices testing in considerable detail. Not surprising, he advocates unit testing of individual services, but acknowledges this is inadequate to determine whether the entire system is functioning properly. He helpfully lays out a series of integration, component, contract, and end-to-end testing strategies that should help developers wrap their heads around one of microservices' toughest problems.
Another problem: You can't always predict which micro services may, under certain circumstances, be overwhelmed by demand. I'm sure that's one reason Karma deployed its e-commerce platforming on AWS (Amazon Web Services), where auto scaling can help ensure no service becomes a bottleneck by adding horsepower where needed. Note that the micro services poster child, Netfilx, also uses AWS -- in other words, micro services and the cloud go hand in hand. Theoretically you could build your own auto scaling private cloud using VMware or Open Stack, but the difficulty of doing that is one reason the public cloud is winning.
Obviously, no one is saying microservices can solve every problem. But microservices architecture may succeed where other service-based approaches have failed, because it's coming from the bottom up. Developers determine the types of services and their granularity, and as the trend spreads to larger enterprises teams can decide which services are best of breed for the whole organization.
That sort of ad hoc build-out would have been impossible with the hardwired infrastructure of the past. Equally as important, developers have grown a lot better at collaborating, with a shift in culture that lends itself to creating software architecture organically rather than following edicts passed down from on high.
From what I'm hearing, in many organizations developers are already employing micro services architecture whether management knows it or not. With the right cloud infrastructure, either public or private, micro services architecture can not only boost developer productivity, but also enable the development of new applications that would have been impractical to build before.
Read More:- Techies | Update
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment