By reading this article you'll learn that ... orchestra (like Emperor) is naked, easy problems sometimes get far more sexy solutions than the hard ones (so screw those), SOA is not dead, microservices in the wild tend to be grotesque & out-scaling can be achieved in several different ways. First of all, thanks for reading this :) I'm quite sure that at least 3/4 of potential readers have dropped off after seeing the word "microservice". And ... I don't blame them at all, I'm fed up as well. That's one of the reasons why I've written this article. Hello (microservice)…
All posts in microservices
TL;DR Deploying 100 times per day is impressive, so is having 5k devs working in parallel on the same codebase, serving hundreds of thousands different API consumers around whole globe or handling fluently interest spike of several millions of new users due to world-scale news event. But there's a huge chance that these achievements are not really applicable to your problem / domain / enterprise, so don't mindlessly copy'n'paste approaches that have served the purpose of solving different issue with a silly hope that they can solve your local problems as well ... Our whole industry suffers from being totally mesmerized by…
TL;DR Modern JS app-building frameworks & libs share one quality - they are component-based. Why not use this (high) granularity to bundle components into small, user journey-focused micro-apps instead of building humongous, complex SPAs. Such model, if applied properly, may bring certain qualities usually associated to microservices into UI layer. JavaScript frameworks & libraries for building in-browser apps have made a tremendous impact on developers' careers around the globe. Angular, React or Ember are among most desired skills, barely anyone even considers building "traditional", server-side-templated MV-Whatever application anymore. SPA (Single Page App) is the king, long live…
There's nothing permanent in software engineering. Consider building services for Internet applications - for the last few years service design principles were quite straightforward: stateless >>> stateful sticky session (& session affinity) are made of suck if you really, really need session, at least make it immutable build a dedicated service layer, but make it as lightweight as possible & keep the state in separate persistent storage If you think about it for a while, it all made sense (still makes!), but ... there's a new Holy Grail bursting in popularity these days (however, to do justice I have…
Few days ago I've run into this article on InfoQ: http://www.infoq.com/news/2015/05/ioda-architecture I found it amusing enough to dive deeper here (link taken from the article): http://geekswithblogs.net/theArchitectsNapkin/archive/2015/04/29/the-ioda-architecture.aspx I won't keep you guessing any longer - my amusement isn't about the overall idea of IODA or this horizontal to vertical (or the other way) thingie - IMHO the best thing about IODA is that it very clearly addresses the problem of (micro)service integration & dependencies between (micro)services. This particular topic is usually (in books,…
The concept of Microservices, even if a bit ephemeral, gets a lot of love nowadays. Reasons are quite straightforward, so I'm not going through that once again - what bothers me is some kind of misconception / overinterpretation I've already encountered few times. Microservices (MS): YES, encapsulate service business logic for coherent & compact slice of (sub-)domain YES, encapsulate persistent data that business logic works on (MS that share the same data aren't really MS!) NO, they aren't supposed to correspond directly (1:1) to slice(s) of actual high-level (for instance: user-facing) applications Why not? MS are NOT a…
Microservices (as a topic) are alive & wiggling. I assume you know what they are about & you've got some clue about the substance of criticism that has hit them. I'm not really that much interested in MS as such, but I'm far more concerned with the general issue of building complex, integrated solutions in a maintainable (long-term) way: testable modular - to distinguish cohesive business services with multiple, intertwined streams of work In short ways - I intent to use the practices of Continuous Delivery in ever-growing, integrated, scalable IT landscape. Thus spoke Udi I've got some thoughts on…