Foreword
People who build software have always been busy, but we seem to be more time poor every year. The expectations of our users and the organizations we work for become greater as software plays a more important role in our day-to-day lives. Against this backdrop, the mantra of “shift left” has pushed more responsibility around things like usability, testing, security, and operations into teams that in the past would be much more limited in their scope. I don’t mean to suggest that the dismantling of silos in software delivery is a bad thing. The movement toward teams with more end-to-end responsibility that came to the fore with the Agile Manifesto and was turbocharged through DevOps is definitely moving us to a more effective way of building software. But at the same time, it means we’re asking ever more of the people in those teams who are absorbing all these new responsibilities.
With all this going on, it is no wonder that people reach for easy answers. When a bandwagon comes rolling along with promises of a brighter future, better hair, and a more magnetic personality, how can we resist? The issue of course is that so many attractive industry trends don’t deliver on that initial hype, and once the bandwagon has disappeared over the horizon, we’re left with the legacy of decisions made in haste. Microservice architectures are no different—while they’ve been great for some people, for others, they’ve left chaos in their wake.
Microservices are simple in concept, but the ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access