Please log in to watch this conference skillscast.
So what criteria do you use to describe the microservices that you have deployed into production? Do they follow the "golden path" of each service having control over every aspect of its self and all its supporting services? Or as you break up the ancient monolith, do you recreate lots of individually deployable services that all rely on each other? At what point does a microservice deviate away from the "one true path"? At British Gas Andy and his Team now have fully independently deployable, scalable microservices, but due to design and architecture decisions (such as supporting JSON API spec) they have created an interdependent tree of services, where at some point or another, there will be a critical service that takes down the entire service. During this Lightning Talk you will learn that no matter how much you try, at some point there will be a service that becomes the lynchpin or keystone of your new services - and it doesn't have to be something that you are control of. DevOps and continual improvement are the keys to success - even if you have micro-monoliths
YOU MAY ALSO LIKE:
Lightning Talk: Microservice Or Micromonolth
One of a team of Architects that shape and drive the Digital Transformation of the British Gas website. Advocate of HTML5 and the move to client side applications running in client Browsers. Advocate of API technology and API's to split the views (supplied by EmberJS web applications) and the data via microservices (supplied by RESTFUL api's using NetflixOSS and SpringCloud/SpringBoot).