How to get into modern software development as an SMB - Part 2 - The Cloud

In the last issue of this newsletter, we covered #cloudnative, and #devops took a closer look into their importance and what's necessary to acquire these approaches for your company.

It may sound odd to start understanding Cloud Native and DevOps first, but it will make sense after a while. I want to address technical decision-makers and developers alike. Still, since we talk about strategic decisions, we should take the viewpoint of something other than hands-on development or code-level: Why should a smaller business go cloud-native?

What is the why? Understanding the destination is the foundation of decision-making.

The most significant difference which comes to my mind when I compare what we did a decade ago and today is?flexibility. Developing applications capable of running natively in the cloud are a different story other than the traditional ways we used to build in the past.?

The slow iterations

The reason was simple we wrote everything in a single extensive application, which was meant to be deployed as a single piece of software onto a hosting server.?Any updates made to the system were major updates?and created a sphere of nervousness for everyone. All employees were happy when developers applied an Update, and not much broke.?But the biggest problem was the missing flexibility.

But the biggest problem was the missing flexibility.

The Legacy Syndrom

With the increasing age of the application, it became more and more impossible to implement more significant features. A change broke another thing, and the fix for that led to another unexpected issue later. Even the way of hosting the app became a silo and only doable by?specific developers with custom niche knowledge about the system.

The application used to become?inflexible, and the terminology "Legacy Application" was applied. So I called it the "Legacy Dead End."

So I called it the "Legacy Dead End."

This specific situation is the point where many SMBs are stranded already. Let's talk about the future already. :)

With Cloud-Native, everything is easy and better, right?

Wrong. Software development is still complicated, and Cloud-Native isn't Maslow's Hammer. Still, it will open your eyes to ways to build apps that allow you to prevent the?Legacy Syndrom?after investing a lot of time and money. So #cloudnative doesn't help you make things easy per se; cloud-native does help you prevent serious problems by providing flexibility and a proper way to modernize your application continuously.

cloud native does help you prevent serious problems by providing flexibility and a proper way to modernize your application continuously.

When you stay flexible, you can focus and move out of a dead-end situation. And dead-ends will appear no matter what.

No matter what we do, in further developments, we will make bad decisions or run into unforeseen problems because we are humans, and this is life. But you will realize that a?flexible application, critical for your business, is an?excellent asset when handling the unforeseen. The following three significant aspects differentiate a decoupled cloud-native application from the traditional monolith.

Iterate your application in small baby-steps

Cloud-Native is flexible per definition. You will be flexible in deciding?what part of your application will receive updates without affecting other parts. Update only the part you need to update, not the entire platform. This approach boosts confidence and Time-to-Market for new features. Technologies like Containers, Serverless Functions, and decoupled Frontends are essential for this approach and play a central role in the Cloud Native way.?

Technologies like Containers, Serverless Functions, and decoupled Frontends are essential

Regulate performance via scaling

In addition, when running into performance issues, you can regulate via?two-dimensional scaling?of specific application parts—scaling specific elements when needed is cost-effective and provides flexibility to react to unexpected loads of your application.

Continuous Modernization - or prevent a Legacy Syndrom

Preventing your solution from becoming a Legacy works the same way. The key is to substitute parts that need to be updated with newer services your developers are creating for this specific purpose, or you want to integrate an available SaaS product. This substitution must be possible without affecting the entire application negatively.?A Cloud-Native application is built precisely that way and grants you the flexibility to move out of the "Legacy-Dead-End."

Decoupling is key. Think services oriented and compose.

To develop for the cloud-native target, you need to think decoupled. Splitting your application into parts means an initial overhead in terms of effort, but it will pay off soon after initial development.

With everything separated, you gain the advantages mentioned above, and most importantly,?you can start thinking in new business ways. With a decoupled application,?you can begin to compose. You have cut your bonds to the old framework, which bound your company.

Composing describes picking available software components, like SaaS or on-premise solutions, and combining them with your application. Next, select your company's specific business domain context and re-think if you need to build your software to cover the ever-growing requirements.

Select your company's specific business domain context and re-think if you need to build your software to cover the ever-growing requirements.

Most companies in the SMB sector have good reason to compose existing SaaS solutions into their application. The reasons are simple:

• Focus your development on your core business
• Reduce maintenance overhead, where you don't earn value
• Save money and time, and preserve budgets
• If it's not your core business, others can make it better.

Integrating an existing solution is often easier than building it yourself. Since small-to-medium-sized businesses have limited resources, it makes sense to concentrate on the integration part of existing software instead of owning the complete development life cycle.