Jul 31

Welcome to the new week!

Let’s start with a short reminder. This week, Wednesday, 2nd of August, we’ll have the next webinar for paid subscribers community.

Together with Jeremy D. Miller, we’ll try to show how to simplify your architecture with Wolverine. It’ll be a live pair programming, where we’ll discuss the assumptions behind Wolverine and how it helps to keep things simple. Check more details on the dedicated webinar page.

Feel invited and join us live!

As promised, I’m continuing to discuss DevOps-related design aspects of Event Sourcing. I bashed the "Will it scale?" question numerous times (see example). I decided to stop bashing and be more proactive. I wrote a guide on scaling applications using Marten.

Oskar Dudycz - How to scale out Marten

It includes a general explanation of the thought process, considerations, and actionable examples of how and when to scale. I’m using Marten as an example, but even if you’re not using it and are not a .NET developer, you should find a mental framework for evaluating storage and event-driven tooling.

Feedback and resharing are more than welcome, as it took me some time to prepare it!

Speaking on the scale. AWS S3 is an intriguing and one of the most widely used tools in cloud computing. It started as blob storage but is now evaluated as object storage with versioning, event-driven notifications and many more. Werner Vogels wrote a great article showing this journey:

Werner Vogels - Building and operating a pretty big storage system called S3

Funnily enough, it starts with the whiteboard drawing. It all starts with the whiteboard drawing, aye? And all look simple, much simpler than it seems. The article explains all the challenges, not only from the architectural standpoint but also physical, like disk storage, managing heat and much more stuff that we might not think about when doing whiteboard drawing. It’s a must-read.

Speaking about heating, physical devices and energy efficiency: unsurprisingly, chosen technology impacts that. What we do and how we use hardware impacts energy consumption. Climate change is undeniable, but it’s not only about being green-friendly. The energy cost is growing and impacting our systems' operational costs. Yes, also on Cloud.

Ionut Balosin did a comprehensive analysis of JVM energy consumption. Even if you’re not in the JVM space, it’s worth reading, as such analysis will be done and also impact your favourite development platform.

Ionut Balosin - Analyzing JVM Energy Consumption for JDK 17: An Empirical Study

We’re hearing that Cloud costs are going down. But not always. AWS started charging for IPv4 addresses, and Corey Quinn says that’s for good!

Last week in AWS - Breaking: AWS Begins Charging For Public IPv4 Addresses

Corey says:

(…) A natural side effect of this is that companies have, in some cases, provisioned tens or hundreds of thousands of public IP addresses for their cloud estates. This poses a problem for AWS, and by extension the rest of us.
The IP address pools are run by a collection of registries, all of whom require a document called an IP Plan that lays out the intended use case for organizations’ allocations, as well as some other data. Companies are required to “make good use” of their allocations, lest they lose them. What this means is that if AWS gains enough big enterprises that are making unfortunate use of their IP addresses, the cloud provider could lose its access to additional IP addresses on the secondary market. In other words, suddenly AWS might not be able to have some services connect directly to the IPv4 internet, which would be bad for everyone.
(…)

So as always, it seems we’re not caring much about the stuff we get for free. It’s also interesting idea we can take for our products. Not always do we deploy the right idea. Sometimes we notice that a feature is misused and brings us more work than benefit. Raising the price for it may be a way to discourage people from using it and maybe even sink it at some point or at least make it more cost-effective.

Read also more on the Azure cloud costs report made by CNBC:

CNBC - Microsoft shares dip after quarterly revenue guidance misses expectations

Newspeak amuses me. We’re saying that growth is slowing down. This means the usage and profits are still growing but growing slower than expected. It almost sounds like something bad. I understand that’s the enterprise budgeting involved, trend analysis, etc. But hey, that’s still impressive and even competition is admitting that.

Sticking with AWS for the last time this release. I told you many times that boring decisions and a boring tech stack will take you far. Last week I discussed LinkedIn moving from JSON to Protobuf format in their services communication. That sounds like all people do, right? It seems not because AWS just added JSON format to SQS protocol.

AWS - Announcing preview of JSON protocol support for Amazon SQS

What was and still is the default one? XML. Yes, XML. Boring decisions; just saying. It’s also a good example of why we should defer our architectural decisions.

Getting back to the scaling challenges. Wix presented a good case study on the engineering work again. This time around, migrating premium subscriptions.

Wix - The Great Migration - How We Migrated All of Our Premium Subscriptions

Wix is a website builder that helps to create and host pages for people that are not developers. I like Wix's engineering blog. They operate on a big scale and are open to sharing it. Of course, I don’t agree with all their articles. For instance, they made the common mistake of calling Event Sourcing what’s Event Streaming. But their content sounds honest and well thought. Even if we don’t agree with all, we can learn a lot about making architecture decisions and confront our ideas with content there.

How do you keep pace with innovation and teach yourself to make the right bets? Check great article (or even a small ebook):

Esther Schindler - Guidelines for keeping pace with innovation and tech adoption

It’s a thorough, multidimensional article we can learn a lot about analysing tech adoption, finding directions etc.

Btw. it’s funny to look back and find how people talked about new things. We rarely go back to see how popular now tools and technologies were thought about when they were fresh. It seems that in 2007 not all people perceived code syntax highlighting as something good:

Linus Åkesson - A case against syntax highlighting

We should do more checks like that for our choices retrospectively.

Focusing on business and using business domain language is always beneficial. I noticed that doing that is too often just assigned to serious backend development. But on Frontend, that in theory is closer to the user (literally), I’m not seeing using business terminology as it should. Too often, we operate on the technical clicks, selection, and textboxes instead of the task, business operations, field names, etc.

Even less often, I saw business terminology in the DevOps configuration. And that also should be surprising (but of course is not), as DevOps should focus on using the same tools, naming and focusing on delivering business value.

Gregor Hohpe in his article showed that it doesn’t have to be like that. Read more and think if that could be also an improvement for you.

Gregor Hohpe - Cloud Automation à la DDD: From stringly typed to affordances

Check also other links!
Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.