Kinja Technology
Kinja Technology
This is a platform for User Generated Content. G/O Media assumes no liability for content posted by Kinja users to this platform.

Growing up as a system - thoughts after Craft Conference

There’s a trending topic at conferences every year. At last year’s Craft Conference a lot was about functional programming, with some hints of distributed systems, devops, and some really good talks about what’s it like beeing an evolving engineer. As it was pointed out in one of the talks, the thing that are in the title of the talks become a single line in them in a few years as it turns from being a new, interesting stuff which you should check out how cool is it, into the industry standard for the companies how don’t fight or ignore them but accept and adopt them. Usually these are the companies who will talk on the next conferences about their successes.


This year’s hot spot was service oriented architecture. The best talks I attended was around this topic, both on architecture side and on the consequences on the human side: how it’s like to be the single engineer and the team who creates and maintains these services. The two sides can’t really be separated: one thing comes from the another and vice versa. You want to design your teams to meet the design of your services to be efficent.

Let’s see what are we talking about. But first, let’s see the things we don’t. If you don’t have an engineering team of 20-30+ people, and you don’t have to deal with hunders or thousand of request per seconds, so you don’t really have to scale, the service oriented architecture is not your thing (yet). If you’re building a whole new product, it isn’t either. It’s premature, you don’t know your boundaries yet which will be the perfect lines for you to slice the application into services.


But if you have a larger engineering team, and a complex product serving tons of requests, you are at the point where you either have a service oriented architecture or you should have one. In this triangle of team size, product complexity and the load your product handles you can’t really put exact numbers on each vertex. Your webshop might have more features than Twitter on the frontend, but at the end of the day, Twitter will be the one who have to deal with the scaling problems like Facebook, not you. The high number of users and user interactions will force a system to have a certain level of architectural complexity or it will kill it. Remember how often you could see the Fail Whale when Twitter was a monolithic Ruby app before they went to Scala and other languages based microservices? How often do you see it now?

When they speak about cons and pros about microsevices, I feel it more like as the different levels of maturity, like the evolution of your own life or your relationship with your girlfriend/boyfriend, spouse, family. As a kid, you have to play, explore, enjoy life, you don’t have to study all the time going to private lessons to be the best. It will stike back. When you’re an adult and have a job, a relationship, kids, you’ll have the deal with new problems every time. It’s just the way life works. You can say that having a family have it’s cons instead of being alone and drinking beers with friends every night. These are problems you can’t escape when you are moving along your life. At least you can’t escape them forever. You can move back to your parents to play video games all the time after having a breakup, but you won’t solve your problems, you’ll just postpone them. The that you don’t deal with these as problems, but with current tasks. You’ll never be out of them, you’ll just face new difficulties as you climb the mountain.


When you start building an application, you shouldn’t start with designing all the shiny microservices. Every successfully working system built by them started being a monolith, and it evolved as it had it’s new needs, new problems, and they evolved when there was the need for it. But when the need was there, it did evolved. Of course there was systems which didn’t, but they aren’t with us anymore. As the current systems ignores these needs won’t be with us either. Microservices add complexity to your system, but they also solve problems. You’ll just have a different set of problems. You can complain about “Why do I have to learn to read and write? If I do that, I’ll have to learn maths and history and all there crap which I don’t if I ignore reading and writing” when you’re 6, but you’ll have a very bad time being a twenty year old withouth all these problems being solved, and you might even enjoy the new challenges you are facing now, all built up on the previous ones. Thank your parents they helped you by forcing you to do all these.

The same way, when you’re having your first difficulties with your firstly separated services, don’t go back to the previous stage. Being a young adult, dealing with all these new problems is never easy, but don’t fight it, you can’t be a teenager forever. It doesn’t work like that. Take the wheel and enjoy the ride you can’t escape.


Thanks for the organizers of Craft for such a great conference. See you next year!

Stay tuned for more coverage on Craft in the next posts!

Share This Story

Get our newsletter