David Schmitz is speaking at Voxxed Days Vienna about failure. Specifically, he offering advice on how to fail at microservices, everyone’s favourite buzzword. We asked him for more insights into how this is possible.
What’s the quickest way to sabotage a microservice?
Good sabotage is not about being quick. You need to be insidious, otherwise you will be found out too quickly. So instead of going fast, I would go the sneaky-route: use processes. “Processes over people”!
Build up an architectural governance team.
A team that is obviously not really building anything, but only drawing pictures, killing other people’s ideas, and in general terms slows everybody down and introduces chaos on all levels.
Management will love this, because words like “governance”, “architecture”, “stability” sound so sweet and craftsman-like!
How can I make my microservice more like my monolith?
There are many options. I would go with using synchronous dependencies to other microservices. This is the easiest way to really couple your services. Just think about the runtime and deployment implications. One service has to be up and running for another service to function properly. And if you are really clever, you can introduce some circular dependencies. These will not be caught at compile time or via Sonar, due to the power of JSON, but only at runtime – hopefully in production by your best customer.
And please, do not use circuit breakers. You need a stable monolith, not some decoupled and resilient nonsense.
Or if you want the low key version: use JEE5 and some big application server. Nothing gives you the nice warm feeling of being at home like handling remote EJB exceptions with some CORBA on top.
Do we really need a microservice architecture on every project?
Obviously not. Microservices are a fad and you should never use that awful architectural style. I mean, look, the pyramids are still standing, that is what I call robust.
In the past, we have built some pretty big monoliths using JEE and good old WebSphere. And they are still standing! Ok, nobody really knows what is going on inside – and if you touch anything, everything will break down. But on the other hand, manual testing is still in vogue, that’s why we avoid unit tests, too.
I think that all these reports of the extreme successes in organisations that moved towards smaller systems, with well defined boundaries, are fake reports.
What’s your top tip for failing badly?
For that you need to come to my talk ;). But I’ll give you another tip, WET (we enjoy typing) is the new DRY. Share-nothing finally gives us the perfect excuse to copy and paste without abandon. Maybe we can go back to the Bonus per LOC systems of the past?
But to be sure, do not copy the tests too. You do not want to increase the code coverage. If only you can maintain the system, then job safety is a given, right?
If WET sounds bad to you, use the pattern “copy and own” – that one sound more like engineering and science.
For more, see Top Tips for failing badly at Microservices: