In this blog, Ricky Severino, a recent computer science graduate from The American University, shares perspectives gained from his internship at Agile Stacks.
This past summer interning with Agile Stacks has been both humbling and inspiring. I’ve realized more than ever the limits of what one can learn while studying computer science—but also how getting the foundations right is the key. What we learn today probably won’t be what we put into practice in the workplace tomorrow…things are just changing too fast.
The first thing I learned, though, is that the cloud is even more important than I realized. Computer science students need to understand how to build cloud-native applications. In fact, they potentially have an advantage in this regard. That’s because cloud-native applications require different architectures and have a different set of best practices from legacy applications, and the students of today have the opportunity to be “cloud-natives’ themselves, without the baggage from years of working with monolithic architectures.
Here are five concrete things, though, that I think computer science students should know about building cloud applications before they graduate and start looking for a job.
There are three main components to the cloud-based model. First of all, what a service like Amazon Web Services (AWS) provides is called infrastructure as a service (IaaS). In other words, you don’t have to think about the underlying infrastructure. This doesn’t mean there isn’t infrastructure out there, just that you have outsourced the server management to AWS. Instead of having hardware on-premises, AWS is handling servers, storage, networking and virtualization. This makes it easier to scale up or down. Rather than purchasing a server, waiting for delivery, unpacking the box, and plugging it in, you just tell AWS that you want more capacity. It’s still possible to get a fair amount of control over the infrastructure, but you no longer need physical resources. For my internship, I got so much done just using AWS’ Management Console to spin up Amazon Simple Storage Server (S3) buckets that I needed for my mini natural language processing (NLP) project. What could have taken days to provision physical storage took just minutes with virtualized storage.
Second in the cloud model is platform as a service (PaaS) where the cloud provider is offering more comprehensive management, and handling runtimes, middleware, and operating systems directly. This gives the organization less control but also fewer responsibilities, allowing them to focus even more on application development. Although my mini-NLP project did not require a super-powered infrastructure, Agile Stacks is built with enterprise-grade performance in mind, which is to say that the platform can handle all levels of application demand. Fundamentally, I learned about Kubernetes but didn’t have to code it since the Agile Stacks platform is a PaaS in many ways. When I requested an environment to build my NLP project, I simply went into the Agile Stacks Control Plane and then deployed the selected components. Behind the scenes, Agile Stacks’ patented-SuperHub did its magic to return to me a fully functioning, integrated and secure environment in under 25 minutes. Doing this at school would take an entire semester, but the technology is pretty amazing.
Finally, you have software as a service (SaaS), which is something most people are familiar with. This is a common model where applications are managed entirely through the cloud. Users purchase a subscription instead of paying to download or license a piece of software. This is common for both consumer and business software and is a cost- and time-effective way to start using software. Many software development tools are SaaS tools. I used Jupyter Notebook a lot for my internship, which ran on the Agile Stacks platform atop AWS. I didn’t need to install Jupyter on my local machine; rather all scripts and algorithms ran in the cloud since Jupyter was served to me as a cloud-native application.
Use the Command Line
Command line functions can be intimidating at first, but they can save a lot of time. Instead of navigating to AWS, logging in, and trying to figure out where in the user interface (UI) you can upload files, you can just type in this command:
$ aws s3 cp notes.doc s3://files/
It’s simple and straightforward. Once you start using the command line, you’ll realize how much time you save and will never go back.
Get Comfortable with Infrastructure-as-Code
Infrastructure-as-code (IaC) makes it possible to automate IT resource allocation and provisioning with code. Automation is one of the keys to successful cloud-native development, and IaC makes it possible to automate not just steps in the software creation process but also infrastructure creation. When done manually, infrastructure provisioning can be time-consuming, but with automation and templates created using IaC, it just takes a few seconds. For example, Agile Stacks engineers use a lot of AWS CloudFormation scripts. I got to see some of the code, and if I didn’t have a great mentor like Michael Delzer, all of it would still be cryptic to me. That’s ironic, since I start a new job in a few weeks as a security engineer.
Things Don’t Always Go as Planned
As a computer science student, you’ve probably already experienced the frustration of something not working, for totally inexplicable reasons. Sometimes a new version introduces a bug or makes it impossible for two pieces of software to work together, even though they did before the update.
It’s very important to thoroughly test everything, and to make sure your tests use the same version of everything—from software to libraries—that you plan to use in production.
Documentation Must Be Crystal Clear
Whether you are the one writing documentation about how an application works or trying to figure out how someone else’s code is supposed to function, documentation is your friend. But that’s only if it is a) done right, and b) you actually look when you need to. If you can’t figure something out, your first step should be checking the docs. In most cases, this will solve the problem much faster than trying to resolve an issue from scratch.
On the flip side, if you’re writing documentation, make sure it is absolutely clear. Under no circumstance should someone have to ask you a question about anything in the software you created. The documentation you write should be so clear that reading it will give you as much information as the creator has in his or her head. One of the things people typically fail to do in documentation is explicitly citing their assumptions. These assumptions should be treated as environment variables. For example, "I performed this locally as the network was too slow to distribute this computation or storage of a value, current measured value is x and local is 10x." In the future if the network is not 100 times faster than x and local is only 50x, it may trigger a refactor. Failure to document these assumptions becomes an example of unconscious bias causing unintentional acceptance of technical debt. These become the source of day-zero vulnerabilities or black-swan outages.
If you get these things right, you’ll be on the right track with your first job or internship. As you start using your computer science skills professionally, remember that there is no shame in asking for help. Things move fast in computer science, and no one is an expert in everything related to software development. Knowing when to ask for help is a skill that will likely serve you for your entire career.
Because there’s one certainty in computer science—things will keep changing—you’ll never be able to definitively declare yourself a master and stop learning.