With three published books under his belt and having attended countless conferences as a speaker, developer Matthias Noback knows a thing or two about his field of work. One of such talks is called Aiming for Autonomous Services, and deals with what exactly a “microservice architecture” means, and how we can achieve true, autonomous services through it.
And what does that mean, really? Well, just as there is no formal definition of the term “microservice” (referring specifically to a software structure), there’s also no definitive model for it. Of course, systems working on that principle will share several notable characteristics, but generally each project also has its own way of working. Because there isn’t a standard for it, there are many different challenges when trying to implement it.
In essence, though, we can quote this definition of the term: “A method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal”
“If you’re working on any kind of setup which requires multiple services to work together on a particular use case”, explains Mr. Noback, “the question is always: how do I prevent cascading failures?” That’s a very important aspect of it, and one of the main advantages of going for microservices in the first place: one mistake doesn’t necessarily bring the whole operation down. He continues:
“If one service is down, the other services shouldn’t go down as well. Every service in the system should be able to work independently. At the same time though, these services should do some meaningful work, like completing an order process; from placing the order, to processing the payment, to shipping the goods”.
Mr. Noback recently finished writing a book, Microservices for Everyone, which has a pretty self-explanatory title. He released it chapter-by-chapter as an e-book, but finally published it in print form on October 5th. The official description states that it is “a catalog of the major design choices you have to make when you’re setting up a system of microservices”.
The book deals with several aspects of using that style of architecture, such as asynchronous integration, independent deployability, continuous delivery, and immediate versus eventual consistency. It also offers further reading material for anyone looking to expand their knowledge about the architecture.
Past books have talked about different subjects, such as Symfony (A Year With Symfony) and software packages (Principles of Package Design). But right now microservices are definitely the focus for Mr. Noback, who lives in Zeist.
Because of their nature, according to him, a system based on microservices “requires a lot of information, as well as coordinated movements”. He presents a “microservice paradox”: services need to work together and be independent at the same time. Aren’t both of those things mutually exclusive?
He was scheduled to give a presentation at Polycon in Barcelona about the subject, but unfortunately had to pull back for unexpected reasons. His talk dealt with two of the general directions one can take to give solutions to such paradox, a subject he surely discusses in his book with more detail.
Coding from The Netherlands
Besides being an author and conference speaker, Mr. Noback also organizes workshops “on a broad range of topics”, which he delivers all over Europe. He does code reviews and general consulting sessions, and he’s also onboarding “an interesting legacy project”, though he doesn’t specify what exactly.
After all of that though, he eventually returns home to the Netherlands. We couldn’t help but ask him about his experience working as a developer there, especially from someone outside of Amsterdam. “The Netherlands is quite alright in terms of software development”, he admits.
The country is not considered to be one of the tech leaders in Europe, but it still pulls some weight and has a healthy dose of startups. “There are some very good developers around. Many of them engage in public knowledge sharing activities too”. Even though it’s a small country, he says there are many PHP user groups, which lead to many opportunities to learn.
However, he does point out three main, common issues he’s seen among several of the companies that he’s visited and are based there:
1. Many businesses revolve around a piece of software, yet they don’t pay enough attention to its quality, nor to its developers
2. Teams that do have time to improve their skills and the design of their code tend to get out of touch with reality and consequentially over-engineer their software.
3. Many developers still don’t (and probably don’t know how to) properly test their software. This results in a lot of legacy code being produced day after day.
All of those are flaws that are surely present on other countries, too. Flaws he has probably recognized in other parts of Europe doing his work as consultant, speaker and workshop host. However, before all of those things, he’s very clear about one thing: “I’m a programmer. And I’ll never quit doing it.”