Cloud-Native – Why Software Developers Should Look Into It
It helps us to focus on what matters.
In software development, we love to focus on what matters, hopefully creating value and pushing the envelope regarding business.
When speaking with other software engineers, especially those who consider themselves developers, they tend to avoid everything regarding IT or cloud operations.
I explain it to myself simply with their focus on design instead of automation. The typical software developer focuses on code, implementation of ideas, changes, and iterations—not so much on where the software will be run.
Software teams often have a “Definition of Done (DoD),” which they hand off to version control or a CI/CD pipeline. That’s it—something happens with the changes, and at some point, there comes feedback.
Take a look ahead
You need to look further than that to take full control and ownership of your development and part of the product. Nearly every Startup and most traditional small-to-medium-sized companies I know host and run their products in the “cloud,” or, more precisely, they consider running their applications cloud-native.
With my articles and videos, I have been very focused on development for the last few months, and since we are at CloudFest next week, I want to shed some light on the cloud again.
What is Cloud-Native?
Cloud-native applications or services are designed and developed to run in the cloud, leveraging cloud computing frameworks and technologies for greater scalability, flexibility, and resilience. This approach typically involves services (sometimes microservices), containerization, continuous integration and deployment (CI/CD), and dynamic orchestration.
The Cloud Native Computing Foundation1 is a very influential instance, even tho they have not coined the term itself.
Native Cloud vs. Cloud-Native:
Since this topic magically comes up, I want to quickly differentiate between the native cloud approach.
"Native cloud" refers to services or infrastructure inherently built and operated solely within a cloud environment. At the same time, "cloud-native" describes the approach and technologies used to develop applications designed from the ground up to exploit cloud computing features for enhanced scalability, resilience, and agility.
A fine by important difference. For example, working with AWS Serverless would be a native cloud approach since you start your work already in the cloud.
🍪 Cloud-Native is, in general, agnostic, while native cloud is often vendor-locked-in and very opinionated.
Why is Cloud-Native an ideal fit for small businesses?
Cloud-Native is developer-centric. Well, it's not the official definition, but the idea behind Cloud-Native is to remove obstacles in IT operations and provide infrastructure to work on. So it's not about the hardware and providing virtual machines in some form; cloud-native is about providing a platform developers can build on.
Especially in smaller companies with 5 to 20 engineers, you often face an absolute majority of developers—often no IT-Ops at all. So, it makes sense to think about a platform that provides developers' needs.
There's a new, old thing that is trendy now: platform engineering.
However, it's redundant for small companies, and I dislike disconnecting Dev and Ops again. You already have the Platform-as-a-Service (PaaS) solutions you need, so you don't need to split responsibility again.
I love to connect the idea of DevOps with Cloud-Native; these two things already go hand in hand since they are very compatible. Furthermore, an easy-to-use Platform-as-a-service model supports end-to-end responsibility.
🍪 Of course, it’s possible to practice DevOps in every environment, but Cloud-Native is basically made for it since it reduces developers' complexity.
The alternatives to CN have never made real sense to me.
I have worked extensively with data centers, Apache, NGINX, and IIS servers, and I don’t miss them a second as a developer. These solutions are powerful in what they can do for you but demand too much from you as a developer-focused engineer.
In addition, you need to meet the quality of observability and resilience, which includes metrics like Mean-Time-To-Recovery (Or TTR these days). This is quite hard if you need to manage Ops alongside your business, so don’t do it.
If everything feels too complicated, you may experience “fatigue,” in which you try to avoid touching things because you are simply afraid of breaking them. This leads to questionable outcomes and qualities.
👉 And yes, this sounds unprofessional; I think we need to focus on what we can do best. Period.
Combined with the simple needs and limitations of SMBs and Startups, traditional hosted infrastructure in data centers or even clouds is not recommendable since it keeps you from doing what you can best: Creating value.
Why developers should go Cloud-Native.
I'd like to discuss the advantages of Cloud Native for software developers and how it allows you to focus on what truly matters: creating value for your clients and customers.
🍪 Only to make sure I have mentioned it, here is it again: We need to focus on creating business value :)
The problem with focus.
As developers, we aim to develop and launch new features while maintaining a seamless user experience. However, managing IT operations, application hosting, and maintenance can detract from our primary Focus. That's where Cloud Native comes into play.
Especially in stressful release times or other constraints or circumstances, we need to be agile and quick; if we aren’t proficient, we are neither.
The variety of "as-a-Services."
Cloud Native introduces various 'as-a-service' solutions, such as Pipeline-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service, and Container-as-a-Service.
🍪 These services are managed by professionals specializing in their respective areas, enabling developers to focus on coding, design, and architecture. By adopting Cloud Native, developers can delegate IT operations to experts, allowing them to focus on their strengths and maximize their potential.
💡I am a developer, and I know from my colleagues and fellow devs over the years that IT-Operations wasn't our primary skillset. Even if I did a lot in this area, I never felt like an Ops-Guy. But, of course, there are exceptions. Especially these days, when it comes to container orchestration and similar complex things, developers should avoid the responsibility of the underlying infrastructure. It's nice to understand, but the challenges in your core business are tough enough.
As smaller companies, take a look into Platform-as-a-Service solutions.
I have mentioned MTTR, observability, agility, and resilience. These are extremely important aspects regarding Service-Level Agreements, QA, stress management, and culture—yes, culture—because if those things aren’t met, you will face stress, which kills culture in no time.
What is PaaS?
I consider platforms ready-to-use for developers. In larger companies, platform engineering teams provide them for dev teams; in smaller companies, this job is often done by externals or freelancers.
❌ So, not the development team itself takes care of setting up things like:
Service Orchestration
Registries
Logging
Monitoring
Load-Balancing
CI/CD Pipeline
Versioning
Backups
Scaling
Infrastructure
IDE
etc.
To manage these effectively in the long term, you need the skills and knowledge to accomplish that and, of course, the focus, as you need this for everything you want to do well.
Small companies and startups should…
be aware of freelancers joining the team and “providing” a foundational and complex infrastructure setup for them–and leave.
It’s not like I doubt their skills; it’s simply because of the fact They aren’t part of the company. They will appear and focus on other things after the job is done. That’s dangerous.
When you are stuck between a company size that can afford its own team of Ops-Engineers or “platform engineering,” you should consider a “Buy, instead of make” decision. Platforms like Vercel, Heroku, and DigitalOcean provide excellent solutions to meet your requirements.
🍪 We run several applications in production effectively on the DigitalOcean App Platform, which is based on Kubernetes. Still, it’s totally abstracted away into a YAML expression called “App Spec,”2, which can be managed via UI, CLI, or Terraform. The scope of the apps is NextJS frontends + 5-10 microservices, with managed PostgreSQL, Redis, and s3-compatible spaces – all done by pure developers ✅
Part of my presentation was when DigitalOcean invited me to the CloudExpo 2023 in Frankfurt. I listed the main benefits of using their App Platform product as PaaS for the webbar.
The fear of the cloud
I want to quickly discuss the resistance to the cloud since I have often encountered it in discussions with CEOs and CTOs during fellowships.
The hesitancy to move into the cloud, as discussed, is rooted in a mix of psychological and practical concerns. Traditional companies often fear losing control over their data and infrastructure, harboring concerns over security and privacy when entrusting their operations to external cloud providers. The apprehension regarding the higher costs associated with cloud migration, especially when misconceptions about direct cost comparisons to data center operations persist, plays a significant role.
👉 It’s crucial to Review the total cost of ownership (TCO). Cloud-Native is compared to data center hosting or renting v-servers, which are more expensive than pure computing power. The logging and monitoring part is expensive and costly to run in the traditional sense.
Additionally, the daunting prospect of overhauling legacy systems for cloud compatibility introduces fears about the significant time, effort, and financial investment required, compounded by a potential skill gap within existing teams. These fears, while understandable, often overshadow the strategic advantages of cloud adoption, such as increased scalability, flexibility, and the potential for innovation and cost savings in the long run.
CloudFest is coming! 🥳
Our team will go to CloudFest3 in Europapark again in the coming week. So, I will focus the coming week on the Cloud and Cloud-Native topic again, as I did last year with my Key-Note “How To Develop A Cloud-Native Culture.”
Some impressions from CloudFest 2023:
Some mentoring advice to keep things simple in modern Software Development:
Keeping it Stupid Simple
As a tech lead or CTO, it's easy to fall into the trap of thinking that you need complex and sophisticated architecture to succeed and progress. You may need the latest and greatest technology or advanced workflows to stay ahead of the competition. However,
Have a great Sunday,
Adrian, snackableCTO
https://www.cncf.io/
https://docs.digitalocean.com/products/app-platform/reference/app-spec/
https://www.cloudfest.com/
Great read, Adrian! I believe using cloud-native while avoiding vendor lock in is very important. At the very minimum you should use containers to deploy, ideally with orchestration (kubernetes or nomad).