"The cloud" refers to both the collective computing power of an interconnected array of servers and the software layer enabling those computers to work together to create dynamically defined infrastructure. Because many consider the cloud the new frontier of computing, it's dominated the software industry for the past several years. Still, your individual level of involvement with it probably depends on your career and how much you acknowledge that you're using the cloud in your computing.
If you're a programmer, you might be looking to move your development onto the cloud, either for work or for fun, but it doesn't take long to realize that choosing a cloud provider can be an overwhelming prospect, especially for an open source enthusiast. I've written about the importance of an open cloud in the past. Luckily, there are very direct ways you, as a developer, regardless of your experience, can help ensure that the cloud fosters and strengthens open source.
Here are five things developers should know about cloud providers and what the cloud means for open source.
The cloud provider doesn't have to define your platform
To develop software on the cloud, you have two choices. You can build your own miniature cloud, or you can buy time on somebody else's cloud.
Building your own is fun. Given enough contributors to your cluster, it can also be effective. But, if you need your software to grow without practical limits, it's probably not realistic to run your own cloud. Buying into a cloud doesn't have to mean you lose control of your computing. A cloud provider essentially is a vendor between you and virtual infrastructure. You need computing power, and cloud providers are eager to sell it to you.
Just like when you buy a new laptop off the shelf, however, nobody's going to force you to use the closed source bloatware that happens to come along with it. When you rent space on the cloud, you can run as many Linux containers as you want, but the interface you use to create and deploy those containers, and the infrastructure those containers connect to, may not be open source. You can think of your cloud interface as the OS and your containers as your choice of Apache httpd, Postfix, Dovecot, and so on.
To run an open source interface, choose to run an open source console, such as OpenShift (based on the upstream OKD project.) If the cloud provider you end up on doesn't directly offer an open source console, look at a service like Red Hat OpenShift Service on AWS (ROSA) that puts your choices in platform first.
The cloud is just somebody else's computer, so trust your provider
If you work with, on, or around computers, even tangentially, you're probably dealing with the cloud already. You probably have at least some understanding that when an application is running inside of a browser, it's essentially running on somebody else's computer (that is, a company's array of servers).
There are plenty of reasons to think strongly about whose hardware houses your personal, organizational, and customer data. However, as a developer, there's also reason to consider the toolchain you build your workflow on. Just because you sign up with a cloud provider doesn't mean you can be forced into a specific toolchain. You should never feel hesitant to migrate from a service because you're afraid of having to rebuild your own development environment. Choose a provider that gives you the flexibility to build your environment, your CI/CD pipeline, and your release model in a way that's sustainable for you.
Developing on the cloud still means developing on your computer
If you haven't developed anything on the cloud yet, it may seem foreign to you, but developing on the cloud isn't all that different than developing on your computer. If anything, it enforces really good development practices that you may have been meaning to institute for years.
Whether it's on the cloud or just inches away from your keyboard, you have a development environment to consider. You have libraries you need to track, manage, and update. You have an IDE that helps you with syntax, consistency, variable names, functions and methods, and so on. A good cloud provider lets you use the tools you want to use, whether it's a text editor, a container-friendly IDE, or cloud-aware IDE.
Open standards still matter
Don’t let the compute nodes fool you. Just because bits are being crunched offsite doesn't mean you have to commit your data to a black box. The work of OpenStack is ensuring that the very foundation of the cloud can be open, which brings cloud development and management closer to your desktop than ever. The work of the Open Container Initiative has enabled applications like Podman and LXC to keep containers open (and daemonless and rootless). Open standards and open specifications empower you as a developer to choose the best solution for your work.
When choosing a cloud provider, don't settle for anything less.
We can build an open cloud
The cloud already powers much of the internet, but it has even greater potential the more open it becomes. Supporting open cloud providers using open source technology is important, but it's just as important to help build it. The cloud, just like our personal computers, the internet, and even our day-to-day communities, is only as open as we choose to make it.
Develop using open source and release open source, on the cloud, on the desktop, and everywhere.
Comments are closed.