Why Swift in the Cloud?

Running Swift on Amazon Web Services (AWS)

In the beginning, there was the server. And thus, the Swift Server Workgroup has their own answer to the question why Swift on Server? “In addition to the characteristics of Swift that make it an excellent general-purpose programming language, it also has unique characteristics that make it specifically suitable for Server applications”. The next question we have to clarify — what is a “server”? For our purposes, we will define a server as including single (or a few) datacenter deployments of virtual private servers (VPS) or bare metal servers.

So what then, is the Cloud? AWS defines Cloud Computing as the on-demand delivery of IT resources over the Internet without the need for the deployment of capital resources to maintain the underlying infrastructure such as physical data centers, servers, backup power generators, etc.

If you are going to deploy projects using Swift, a server is not the only option. Do you choose a server or the AWS cloud? The same characteristics that allow Swift’s superb performance on a server, also extend to running in the AWS cloud. Both systems are tools with their various strengths. The choice to be made is about more than just personal preferences. Without a deep dive on the issue, the argument for/against boils down to complexity. AWS can be complex as it offers far in excess of just a server deployment:

• Technological complexity — requires specialized knowledge just to get going
• Budgetary complexity — it can be difficult to determine exactly what things will cost

To give you a better idea of what the challenges are I will address this in terms of tradeoffs.

Tradeoffs between options are multivariate and have consequences through time. Choose your narrative carefully.

Approaching the problem via the tradeoffs makes it clear what it is you are choosing and what downstream effects it will have on the resources you need. If you are just starting to use Swift on Server and you haven’t given much thought to what the “cloud” means, then you might want to rethink the possibilities. My personal opinion is that you should wholeheartedly move to the cloud if:

1. You will write (and maintain) custom code for your solution
2. You will use AWS services to replace generic compute wherever possible
3. You will use distributed, scalable and serverless custom compute

In addition to the characteristics of Swift that make it an excellent general-purpose programming language, it also has unique characteristics that make it specifically suitable for Server applications. — Swift Server Workgroup

In general, if you have not adopted these, then you are likely taking a server approach and dropping it wholesale into the cloud. And why not? Do these points really matter?

1. Write & Maintain Custom Code

Custom code use is a point that I find is often omitted from any discussions about the cloud. I suspect that it is an implicit assumption that those in the know understand. Those who do not, fail to consider it’s implications. The mostly bundled primitives offered by a server tend to map almost directly to the product that is running on the server and is user facing. Think Wordpress. That is a system build for server deployment. It has been adapted slightly to scale using elements of the cloud and content delivery network (CDN) services. Fundamentally though, it is a system designed for server deployment.

In the cloud, the primitives tend to be built as distributed services that implement functionality used to build scalable, fault tolerant solutions. As abstractions, they often do not map as directly to the result displayed to a front end user. It is often much more difficult to find cloud products that are sold or open sourced as off the shelf solutions that can quickly be run in a serverless cloud environment. You will therefore need to map the behaviour you want the user to see, to these scalable backend solutions which will require a decent amount of your own code. This code will also need to change and improve over time as you learn more about the systems you are building on.

2. AWS Services vs. General Purpose Compute

On demand general purpose compute is expensive. AWS offers services that are optimized to deliver solutions with the greatest reliability, throughput and lowest cost. If they offer a service, they can generally do it better than you can at a cheaper cost. This is a no brainer to use their service instead of paying more to build and run your custom solution to achieve the same goal.

Much of the existing software out there are not at all designed to run in a distributed and serverless environment. So out of the box, you will likely be out of luck. Writing code for a serverless environment requires a complete rethink of how to best achieve your goals. The best approach is to focus only on your core code that creates value. For everything else, use the provider service that is optimized for the abstraction you require. Again, this will feel very wrong coming from the server environment where a Wordpress installation is a quick and easy process.

A good example of this is AWS Simple Email Service (SES). Sending an email seems like a simple thing. Sending an email that will land in the customer’s inbox each time, requires a suite of services to manage your email sending (there will be a detailed explanation of this this in a future article). This is not something you want to reinvent, but you are better off using AWS SES. The ability to rapidly make changes is important for finding the right product market fit. Let AWS services take care of everything else. Instead of spending time implementing well abstracted and performant functionality, you focus on value.

NB: this also explains why much of the software being built today is only offered as SaaS using the subscription billing model as it fits much better with cloud build software than single server options.

3. Distributed, Scalable & Serverless

As mentioned above, the main benefit of cloud computing is to be distributed, scalable and serverless. Distributed means your services are replicated across multiple data centers, regionally or globally if necessary. Add High Availability and your services should see little to no perceivable downtime to the majority of your customers, only degraded service as systems compensate. Scalable means your the amount of compute you are using can scale up and down depending on your needs at any time. Any sudden surges in traffic can be absorbed. You only need to scale up at any given datacenter as needed. And if you do need a baseline of steady state capacity, you can pay in advance for that and get it more cheaply. Serverlessmeans you do not need to manage the underlying server systems. You simply specify your compute needs and your service will be deployed to run. All three of these combine to have the effect of being able to serve your customers wherever they are, in an efficient and performant way.

The Options Explained

While there are many services on AWS Cloud, we are going to provide you will detailed instructions and the code to make use of Swift runtimes using AWS Lambda, DynamoDB, Simple Email Service (SES), Simple Storage Service (S3). These are the basic services that will allow you to replace the core abstractions that make up web services and software today. Lambda replaces custom compute, DynamoDB replaces key-object storage/database, SES replaces email management and S3 replaces file management.

See you soon.