Programming principles and microservices maintenance [BoilingFrogs2017 #1]

When I was leaving my warm, sleeping fiance at 5 am, I was thinking “Why the hell am I doing this to me”. But I knew I wouldn’t regret taking that train to Wroclaw. So many people were excited about this conference that it just had to be great! ;)

Boiling Frogs is a Software Craftsmanship conference, which means it didn’t focus on just one technology or programming language, but rather generally on good practices when developing systems and managing teams. And that was great. There were so many different theme paths and topics, that everyone could find something interesting for him or her. That was the first time I took notes during the lectures. It helped me to focus on the topic and extract things worth remembering.

Fun fact – there were many women on that conference and that is really great! :)

Back to forgotten roots

This was the first presentation that I attended, since I was a little bit late. It was such a great start! Lately all that I was hearing was: OOP is obsolete and passé! Moar frameworks! The so called “hype driven development” was driving me mad, frankly. I agree with everything that was said during that presentation:

we should write trivial code - easily understood and functional. Most of the time we spend READING the code, not writing it, so sometimes writing several more lines for the sake of readability is great.
we should exp our toolset :) - we need to know little something about each technology, to be able to choose the best one for the project. However, we have to be prone to the hype driven development and really judge whether this new cool JS framework will be a better fit for a project developed by .Net team.
we should question documentation – official docs usually present the most naive approach towards some problems and many people just blindly copy paste them into their projects. Mariusz mentioned the Symphony framework documentation, where you can find some anti patterns implemented.
we need to dive deeply into the specification received from the client – many people just briefly glance at these fat pdfs and rush into coding. The speaker recalled a situation from his own experience, when he refused doing the project, as he saw it as unprofitable for the client. At first the client was surprised they do not want “easy money”, but then he realized that they’re acting for his own good, and now they have been cooperating for several years.
we have to remember to always solve problems that are worth solving. We need to be able to fill such sentence: “WE USE … TO BUILD … FOR … TO HELP WITH …”
be aware and remember about some programming principles that are present for many many years but sometimes we tend to perceive them as obsolete:** SOLID** and GRASP (general responsibility assignment software patterns). I’ve heard about GRASP for the first time, so I can only tell that it consists of 9 patterns, which help us in deciding which responsibility should be assigned to which object or class. I’ll definitely dive deeper into this topic in one of the future posts.

These are tips that I caught and wrote down during the presentation, but I look forward to watch the video to hear all that wise things again.

Presenter: @mariuszgil

SLA and microservices maintenance

That was another great presentation. I’m not really into microservices for now, but if I was to maintain such system, I would really benefit from the lecture. Best part about writing blog posts – I can store safely thoughts that I might actually need in the future. :) The speaker was certainly very experienced in the topic of microservices maintenance and pointed out a few things to be aware of when dealing with them.

First of all, two things to remember when designing a microservice:

• team dealing with that service should be able to fill up on two pizzas,

• bounded context for the win! ;)

One of the greatest advantages of creating microservices is their autonomy, as it greatly decreases the amount of problems connected with new releases. However, to be able to fully benefit from that, we need to utilize the power of CI (Continuous Integration).

Things to keep in mind when working with microservices:

• maximizing asynchronous communication between them,

• loose coupling of the components,

• e2e tests do not work in case of microservices, as it’s too hard to maintain a whole working system,

• design for failure – two approaches:

fail safe – we do everything we can so there is no failure – DOESN’T WORK, as failures are gonna happen sooner or later, not necessarily because of bugs – I guess you can just remember the AWS outage that caused the failure of half of the Internet few days ago,
safe to fail – prepare for the problems and create emergency paths, for example “keep calm & fallback” – just stop the operation if there is something wrong, </br>

• test critical paths – “AS ASAP AS POSSIBLE” – it’s easier to find the cause of the problem when there is CI implemented as it’s easier to find the changes that introduced bugs,

• keep in mind that there might be problems with performance, as it will drop in case of microservices (communication between them can cause it),

• the sad thing is performance tests are expensive and inaccurate, as production traffic is production traffic and it’s really hard to simulate it,

• this is why we need solid monitoring,

• automation, automation and once again – automation:

pipelines as a code,
infrastructure as a code,
configuration as a code. </br>

Presenter: @jkubrynski

As this post started to swell, I decided to write another one about the rest of topics and overall impression of the conference. The last presentation that I attended was about Serverless Architecture, the thing that I was really interested in lately, so I took maaaany notes. ;)

This is the first post taking part in Get Noticed 2017 contest. I created a newsletter, so if you’re curious how I’ll manage to deal with the next 19 posts, subscribe! :)

And as always - like my fan page or follow me on Twitter to get notified when future posts appear. (｡◕‿◕｡)