I once again had the opportunity to present at the Brampton DevOps / Cloud Computing Meeting. This session was focused on a series of rapid-fire lightning talks. There were a few really great talks on “Automating Legacy” and “Next.js with Now”. All around a great and fun evening.

My lightning talk focused on 6 software architecture trends that have been on my mind since attending ArchConf 2019. It was a great conference, with some incredibly talented presenters and architects. This made it a perfect opportunity to reflect on 2019 and think about what is not working and what is working both internally at SPS Commerce and externally in the tech community in general.

While I won’t recap the entire presentation, here is a brief overview… let me know what you agree with, disagree with, or think should be added to this list:

1. Distributed Teams: Remote work is the new norm

Recent stats show that around 70% of the world works remotely in some way at some point during the average workweek. That is a huge number, and likely much higher than you thought it was (I know it was for me). Additionally, the same measurements show that when working remotely employees are 13% more productive at the same time. I wonder why that is?

• Faster context switching, switching meetings virtually, etc…
• Employees take more ownership of their work and feel trusted by the organization. In turn, the employee wants to give back to the company.
• 9-5 boundaries begin to disappear, as flexibility is provided to the employee.
• Fewer distractions (though sometimes distractions and water-cooler discussions are good).
• Exciting to see the pool of tech talent be expanding by considering new geographic areas for remote hires.
• Interesting comparison between the rise of distributed computing and distributed teams together over the last decade, both seemingly enabled by technology.

2. Continuous Deployment: Rarer than you think?

Contrary to popular belief “not everyone” is doing continuous deployment. Sure continuous delivery is entirely standardized in DevOps mentality now, but continuous deployment is REALLY hard to do well and has many inherent risks that come with it.

• Is continuous deployment more of a culture and mindset than something physically to achieve?
• The cost entailed in building a platform into full continuous delivery may not be worth the value it provides.
• Feature flags “blur” the line of when something is actually released and have a bearing on the culture and mindset itself.

3. Microservices: ARE DEAD…no, they are evolving! FINALLY!

Simply put, a Microservice architecture in its purity is more expensive often than we want to admit. We pay the price in dealing with granularity. Technology enables this level of granularity, but that doesn’t mean we don’t pay for it through higher management costs, infrastructure costs (DB isolation alone is costly). This forces us to think for the monoliths we are decomposing if the organization would benefit from a better balance, focusing on a tiny or small service architecture instead. Better yet let’s focus on asynchronous workflows and streaming technology to enable the services we are building.

• Cost forecasting is usually highly inaccurate as architects attempt to predict the outcome of their proposed microservice architecture.
• Code reuse is really hard. Microservice architectures demand next to no reuse between services, yet as engineers, we are biting our teeth as we copy our code. Face it, code reuse is a hard thing to manage, and microservice architectures don’t help you with that, the ignore it. What kinds of code are you sharing in your microservices?
• The fallacies of distributed computing are consistently forgotten in microservice design (myself included at times). The network is simply not as reliable as we all wish it were.
• RESTful APIs are primarily used to communicate across components instead of considering other alternatives for communication. Too many RESTful dependencies can easily be the death of your architecture (can you say: “spaghetti”?).

4. Cloud Infrastructure: Not everyone is in the cloud nor are they moving to the cloud!

While my naive first thought is to believe that everyone should be moving to the cloud since it enables my team and I to provide immense velocity with what we are building, there are many reasons why the cloud may not be the right choice! In fact, some organizations are moving away from the cloud, including Dropbox who saved over $74.6M in data expenses.

• Data is expensive in the cloud!
• Not all organizations trust cloud security, or they themselves provide a differentiating capability in the security space.
• Organizations may want to retain and control their own destiny. This is actually much like AWS’s own philosophy in bringing hardware design and manufacturing in-house (or even Amazon with courier services).
• Azure Arc and AWS Outposts are the next big trend to meet the need of those staying in the data center.

5. Consumer-Driven Contracts (CDC)

I was introduced to CDC at ArchConf this year, and love the concepts that it enforces, and I look forward to diving into it deeper. Rather than attempt to explain it here… go check it out yourself. After you understand the concepts, have a look at pact.io to help you enable it in your organization.

6. Data Lakes: Falling out of favor?

I’ll be honest, I always struggled with data lake concepts a lot. The idea of working with unstructured models and data in production simply didn’t make sense to me. From what I gather from others over the past year and some of the internal technology changes within SPS, this sentiment rings true with others.

• Working with unstructured schema/data in production systems results in difficulties to reason about the system and has performance trade-offs.
• Using data lakes for analysis to derive your production model is a great niche for it (and of course general data science/analysis).