Amazon Compute: To serve or not to serve?

04 May

Episode 68

This is the fifth article in the Amazon Web Services Series so far (or sixth, if you consider the cloud computing intro a part of it). Within three weeks, we went through a list of all currently available AWS services and then, in the previous article, we focused on storage category: S3, Glacier, EFS and EBS. Today we are going to dive into the compute category, particularly EC2 and Lambda services.


EC2 and Lambda represents two main computing models we can consider when hosting any application in AWS. We can have a server – a classic virtual machine, either with or without containers, or we can bypass all that and just run a piece of code as a function. Let’s look at both solutions and compare.

Elastic Compute Cloud

EC2 was introduced by AWS in 2006, and in 2010 the entire Amazon retail business switched to it. In essence, EC2 service is about providing virtual machines, or computing instances. Instead of buying physical servers and taking care of them, we can just buy time of the machine, get more when our needs grow and discard if they shrink as with everything in the cloud. Instances come in many different sizes and shapes, so let’s take a quick tour on available categories. Each type comes in 2 to 7 variants, e.g: t2.nano, t2.micro, t2.small, t2.medium, etc. You can find more details on here.

General Purpose, starting with cheap T2, good for development environments, small web hosting or fine grained micro services. Then there are M3 and M4, for small and mid-sized databases, and back-ends utilizing more resources.

Compute Optimized C3 and C4 features high performance processors and are suited for batch processing, science and engineering applications and encoding.

Memory Optimized R4 and X1 instances features up to 2TB of fast RAM and are recommended for in-memory databases, data grids, and custom big data processing.

Accelerated Computing instances contains a bit different hardware. P2 and G2 instances have Nvidia GPU units while F1 instances offer custom FPGAs. Use cases include scientific research, video processing, 3D rendering, machine learning and others.

Storage Optimized I3 feature fast NVMe SSD drives, while D2 instances can have up to 48TB of storage, suited for big data, databases and distributed files systems.


EC2 instances can be used in three modus operandi:

On Demand instances are charged per hour, whether they are really used or remain idle. Suitable if we can’t predict our future capacity needs.

Reserved instanced can be booked for much longer period to offer considerable savings. Good if we are certain about the minimum capacity, or when our application starts slowly.

Spot instances time is sold to the highest bidder, but we can lose it instantly if someone outbid us. Useful to cover rapid spikes of capacity needs, big data processing. When we don’t care much about sudden application termination and we can start quickly. Some institution invest a lot in spot instances management solutions to optimize costs further.

Meet the Lambda

“No server is easier to manage than no server” is the embodiment of hopes of serverless computing, a recently emerging trend, also known as FaaS – Functions as a Services (yet another acronym to our aaS collection, started in cloud computing intro). The idea is that, instead of deploying an entire application along with its frameworks and libraries on some kind of server, we deploy only a Lambda function – a small piece of code that will trigger on particular conditions, receive input, execute its code and return some kind of output. Of course, it doesn’t mean that there is no server somewhere, it’s just transparent to us, we delegate its management to the cloud. We even go a step further and delegate the application and frameworks to the cloud, we only supply a piece of code to be executed. You can find an extensive article on the topic on Martin Fowler blog.

AWS Lambda was introduced in 2014. In this service, we are charged per each 100ms of our code execution. Supported languages are Java, Python, Java Script and C#. The function can be triggered on events from many other services, like S3, Kinesis, databases, IoT devices activity or HTTP request. Typical use cases are: generating image miniatures after upload to S3, acting as IoT or mobile devices back-end, sending customized notifications. Lambdas are not suited for long running task, as there is a limit of 5 minutes for execution time. The advantages and disadvantages over classic approach will be the focus of the next paragraph.


Pros and Cons

Serverless architecture advantages:

  • It simplifies small application development and deployment if we don’t have a good CI / CD environment in place.
  • We pay per execution, not per hour, so we can really pay for what we use.
  • Flexibility in terms of serving traffic spikes. Of course, we can orchestrate fleet of T2 instances to start when the spike occurs, but if its short, we are left with unused capacity for some time.
  • Fits well with microservices architecture.

Serverless architecture disadvantages:

  • We are in a vendor lock in. What if we decide to move away from AWS? What if AWS goes bankrupt (however unlikely it might be)? Classic web application can always be put on another standard web server on any machine.
  • We give up the control over the web server and possibility of fine-tuning it.
  • First invocation of a function after some time might be slow, depending on how the provider orchestrate environment behind the scenes.
  • Diagnostics and debugging of the code might be much harder than the code we run on local server during development process.
  • We don’t control how our code is run in regard to other cloud clients, which might lead to security or compliance concerns.
  • We can’t depend on in-memory application state. If we use other means to achieve that, like data grid or other external storage, but the performance will suffer.
  • Finally, serverless solutions are not yet mature, so the tooling to support development is still not there entirely.

So, go or no go? As usual: it depends.

What’s next?

There are few other services in compute category, but those are mostly supporting ones and I’m not going to dive into them today. The focus of this article was mostly to confront computational models available on AWS. If you found it useful and wish to motivate me – comment, like, follow, share, subscribe. I won’t sell your email to Russian mobsters, I promise (or at least not cheap…). See you next week!


Image sources:


Posted by on May 4, 2017 in AWS, Cloud, Technology


Tags: , , , , , ,

5 responses to “Amazon Compute: To serve or not to serve?

  1. Adam Owczarczyk

    May 15, 2017 at 6:25 pm

    Disadvantages aren’t so bad.
    1. If you use Serverless, you can mitigate a bit vendor lock-in
    2. The functions should be small by design, and running for infrequent tasks. If you need low level fine tuning, you are doing something wrong, and should probably look at EC2.
    3. Agreed:)
    4. Haven’t found problems debugging so far. Standard logging libraries, nothing fancy or complicated.
    5. Lambdas can run in VPC, and using specific roles. No idea what compliance problems there might be.
    6. We kinda can. If you declare something (like service connection object) outside the main function, it is likely to be cached for future reuse.
    7. :)



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: