In this inaugural blog post, I will introduce a concept I call “Cloud First.” I will frequently refer to this notion, and the ideas behind it will be a common denominator for many future post topics. I will start my blog with a few foundational concept posts, and this post is a perfect one to start things off.

Cloud Success and Failure

You don’t have to look far to find numerous success stories of companies moving their systems and products to the cloud. At the same time, there are plenty of stories where things don’t go so well on the cloud, and companies will decide that the cloud is not the right direction and move back to their company data centers. Then there are cases where things may have gone well but not quite meet the expectations or the standards required, and the plans are aborted or completely reversed – pulling their operations back into their own data centers, a process known as ‘Cloud Repatriation.’

For the context of this article, I am not talking about cloud operations such as spinning up temporary virtual machines for development, testing, or quick and temporary computations. I’m referring to the typical development and cloud deployment of custom line-of-business software solutions. These could be internal business support services or, more commonly, services being licensed to customers.

The reasons for things not going well are many and varied. What’s more consistent, though, are the common patterns followed on the path to success. You might be one of the lucky ones who jump in with both feet, figure things out as you go, and things work out. I believe those stories are few and far between. Consistent success stories start with project teams that understand that to be successful on the cloud, those teams need to rethink everything. Over many years and possibly even decades, project teams have established standard ways of doing things. Many of those processes have worked well, but let’s face it: every project team has some nagging issues dragging down the team that keep them from reaching their full potential. The longer those go unaddressed, the more things become bogged down and suffer.

Rethinking everything doesn’t necessarily mean changing everything. It could just mean a few things need to change, and a few need improvement. It requires an honest, reflective look inward and an assessment of what needs to change to make a more responsive, dynamic, and efficient team and deliver more reliable, maintainable, scalable, and performance-focused code.

This is a list of just a few things that you may consider

• Is your code designed to be testable?
• Is your code loosely coupled and designed within bounded contexts?
• Do you have a highly effective suite of automated tests?
• Are you utilizing modern build and deployment pipelines?
• Are you implementing infrastructure as code techniques?
• Does the structure of your code follow modern best practices?
• Is your code highly scalable?
• Is your code designed and written with performance in mind?
• Is your code resilient and reliable?
• Is your code written with security as a focus?
• Are you using versioning effectively and adequately?
• Are you effectively utilizing packaging and artifact stores?
• Is your code maintainable, and can it evolve quickly?
• Are you using Agile methodologies?
• Are you properly utilizing work tracking tools?
• Are you using modern and mature patterns?
• Are you best utilizing code repositories and branching strategies?
• Are your processes and procedures cost-effective?
• Are you employing effective observability (traces, metrics, logs)?

This list is not exhaustive and could go on for pages. Each of the topics listed could also be significantly expanded with sub-topics, and so on. Conversely, these could all be folded up into two primary top-level issues: Security and Cost Efficiency, which coincidentally seem to often be the primary concerns of companies that are hesitant to move to the cloud and many of those who have moved back from the cloud to their own data centers.

Cost efficiency has direct and indirect relationships to many of the other topics listed above and many that are not listed. If your code is not scalable or performant, your system is unreliable and not resilient, your processes and operations are inefficient, and you can’t quickly fix bugs or deliver new features; these all result in financial costs. These costs are also two-fold. There are direct, immediate expense costs and lost potential customer revenue.

Assess all aspects of your processes, operations, and products to achieve a highly successful and cost-effective journey to the cloud. Break free from outdated and inefficient methods that have become comfortable due to familiarity. This same assessment and approach significantly benefit other software projects and teams as well, even without plans to move anything to the cloud.

First, ask yourself if your code and development practices qualify as ‘Cloud Native’.

Cloud Native

There are likely hundreds of definitions out there of what Cloud Native means. For this article, I will refer to the definition provided by CNCF (Cloud Native Computing Foundation):

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is non-exhaustive.

I will focus on the first paragraph of that definition because the second paragraph would not apply to many projects that are not destined for cloud deployment. I want to focus on common practices that help cloud-native applications be successful and can be applied to any software project. To stress a couple of points I think are missing in that definition, I am going to elaborate on the definition and add a couple of things

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) with great cost efficiency to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, observable, and highly performant.

I would also add maintainable and testable, but those could arguably be included with ‘manageable.’

Applying the ideals of this definition diligently to every project is what I refer to as a ‘Cloud First’ approach.

Cloud First

The term ‘Cloud First’ has its roots in the concept of ‘Mobile First,’ a principle of designing web user interfaces that are effective and usable on all form factors. Mobile First is defined by MDN (Mozilla Development Network)

Mobile first, a form of progressive enhancement, is a web-development and web-design approach that focuses on prioritizing design and development for mobile screen sizes over design and development for desktop screen sizes. The rationale behind the mobile-first approach is to provide users with good user experiences at all screen sizes—by starting with creating a user experience that works well on small screens, and then building on top of that to further enrich the user experience as the screen size increases. The mobile-first approach contrasts with the older approach of designing for desktop screen sizes first, and then only later adding some support for small screen sizes.

While Mobile First is a technique for web interface design, Cloud First is a comprehensive principle that applies to all aspects of software engineering. Using the structure of the Mobile First definition as a template, I will define ‘Cloud First’ as

Cloud First, a software engineering principle, is an architecture, design, implementation, and operational approach that applies cloud-native best practices and patterns to all development projects and all deployment models. The rationale behind the cloud-first strategy is to enhance product quality and make project teams highly productive and cost-efficient while delivering more features and working less on problems – by providing code focused on security, performance, scalability, testability, maintainability, and reliability while employing long-established best practices as mandatory and not optional and by looking at all aspects of code and operations through a cloud-native lens, while reducing technical debt accumulation.

The cloud-first approach differs from older methods that only meet minimum standards until they become inadequate. These traditional methods accumulate technical and operational debt, are incapable of adequately evolving, and eventually require major refactoring and re-tooling, which causes delays, reduces productivity, and hinders feature delivery.

Apply Everywhere

Clearly, cloud-native practices cannot be fully applied to every project. You aren’t likely to have a full CI/CD pipeline setup or develop microservices for a desktop application, and these concepts are likely not applicable to an embedded system project written in assembly. However, successful cloud projects provide great examples of how virtually any project and team can improve, and those examples serve as ideals to model after so every project can take a cloud-first view of their processes, architectures, designs, and code.

Summary

I discussed the landscape of successful and unsuccessful cloud-based projects in this article. I focused on patterns and practices that can serve as examples to model after for any project, whether those projects are greenfield cloud projects, migrating to the cloud, might someday be migrated to the cloud, or will never be a cloud-based product.

I touched on cloud-native practices and defined ‘Cloud First,’ which parallels a general approach in ‘Mobile First.’ While ‘Mobile First’ focuses on designing for mobile screens first, ‘Cloud First’ emphasizes first asking the question, “If my project was cloud-deployed, how would I do things differently?” and adapting as necessary to meet project constraints.

This is simply an introduction to the concept. In future posts, I will examine many aspects of the cloud-first principles and how any project or team can benefit from them, focusing on numerous aspects of code quality and general software engineering best practices.