4developers – thoughts after the conference – part 1 (Azure + Architecture)

Serverless in Azure and software architecture – that’s the content for today’s post about 4developers conference I attended yesterday because if I’d put everything that’s worth sharing in one post it would be far too long. So I decide to slice it a bit.

Serverless in Azure

There were two lectures covering that topic – from Gutek and Łukasz Kałużny – both were really interesting. We’ve been pointed out that Serverless approach is nothing new – it is in ‘use’ for relatively long time already, actually since cloud (which some of us calls ‘somebody else’s computer’ 🙂 ) is present on the market. The thing that has changed is charging really – we no longer need to pay for hosting our whole server, but we’re charged by actual use of processor/function call or similar. Fair deal. This is what we can extravagantly call ‘serverless’.

There was also a comparison of Azure functions with its equivalent on Amazon Web Services. Although AWS is a more mature cloud, precisely Azure functions seem to be a better solution on Microsoft’s portal.

Functions on Azure are also a nice option as far as they’re free till 10,000 executions per month, so if you can make use of them and won’t bring too much traffic 🙂 then check it out.

You may also be interested in which is a small yet great device which can be easily set with Azure to set some workflows out of the box. Łukasz showcased how you can easily connect such little IoT item with e.g. temperature scanner, make few clicks on Azure’s portal and have a ready-to-use system which informs you about sudden temperature increases by SMS. Cool stuff!

Architecture – transformation

Architecture is made by people. Architecture is people. That’s how the architectural lecture has started and ended – with the most important statement Pedro wanted to give us. Luckily it’s not the only one I remembered 🙂 This session was more like a story he experienced during rebuilding few systems in various companies, but I can explicitly put out few conclusions here:

  • Architecture transformation is never easy. You should take an approach like during eating an elephant – taking one bite at a time.
  • Sometimes you’ll need to take bigger bites. Nevertheless, try to do it gradually.
  • Don’t expect the results just after you made efforts. At the beginning, you’ll have even more lines of code, which will be more complicated, and your work outputs will be below your expectations. Be patient.

Architecture – creation

Another vision on that topic was brought by Daniel, who brightly spotted, that good architecture we desire is not the perfect architecture. He committed such ‘perfect’ architecture once, but he found his team in a situation where he was the only one who was actually understanding the code. And was capable of developing it. But! Uncle Bob would have been proud, for sure! 🙂

This was far overengineered. Madness.

He also tried an opposite resolution and let his architecture be driven by the customer. Which means it was redesigned each time customer requested a new feature to his product. After some time he realized this was not a good idea because underengineered Spaghetti Monster killed half of the team.

Madness. Again.

‘Wat do’ then? There is no gold rule here I guess. Similarly as in unit test, when you ask: “Hey, what is the good coverage in unit tests?”. The proper answer is: “Somewhere between 0% and 100%”. You are the one who has to adjust it to your specific project.

Same thing in architecture – what is the good one? The one which is somewhere between under- and over- engineered definition. How can I guess that I’m in the good point? You must practice, to gain experience. To gain sort of architectural intuition what can be extended by the client in near future and what can be ‘hardcoded’ to save some time and not take technological debt there. Let yourself fail to learn for the following projects.


No summary today as the topic is not exhausted yet, this is only the end of part 1. On the following, I’ll tell you what I learned in terms of Azure Bots, GraphQL and what interesting questions were addressed during discussion panel.

I hope you found this post valuable and see you next time! Thanks for reading!

Somewhat experienced programmer who tries to find intrinsic meaning in each act he does. Increasingly builds his courage to let his life be driven by passion. Currently giving blogging a whirl.

Leave a Reply

Your email address will not be published. Required fields are marked *