Redpill Linpro

4 reasons why a container platform is the right way forward

Tue, 13 Apr 2021 00:00:00 +0000

You might have heard about containers and how they greatly benefit innovation, but why?

A container platform, or Platform as a Service (PaaS), is in many ways the wheels of DevOps and Agile delivery. In short, these platforms make it simpler to run and develop applications.

As the name container itself implies, all the dependencies your microservice needs to run is packed into a standardised carrier. It now has an environment to run and a clearly defined interface in order to communicate with other services.

Containers also facilitates the growing popular idea of decoupled architecture. The application architecture is split up into smaller microservices which then run in separate containers. Each and every container is then run on top of a container platform, and orchestrated automatically by services such as Kubernetes and OpenShift. This decoupled architecture is the modern way of Software Engineering.

Below I have collected the top four business benefits and opportunities for moving over to a container-platform:

1. Easy to get started with

Whether you struggle with a monolithic legacy application, or are just starting up, a container platforms is relatively easy to get aboard with. All major cloud providers offer their own container Platform as a Service. Meaning, in all simplicity ,you only need to bring your code in order to start running your applications.

From a startup’s point of view, it is essentially plug and play. But even companies struggling with legacy infrastructure can make fast use of PaaS platforms, by shaving off and rewriting smaller parts from a monolithic application. Gradually migrating to a segmented container platform.

2. Higher productivity

As noted earlier, containers drive DevOps and Agile delivery. Splitting up your architecture into smaller services, makes it easier to maintain, develop, debug and add features to your code. Setting up a container platform with Continuous Integration and Continuous Deployment (CI/CD) in addition, will provide a self-service platform. Then you will no longer depend on operations provisioning the code on test, staging or production platforms. CI/CD lets developers test the code and deploy it themselves, but also roll it back if there is a problem and then roll out again after a fix.

Smaller, faster releases result in faster development cycles and ends in higher productivity.

3. More time to innovate

Companies undoubtedly need to evolve and innovate fast to keep their customers continuously using their services. However, normally far too many IT resources are bundled up in maintaining and managing legacy infrastructure. This means less time to focus on improving and on innovation.

Container-platforms can be automated all the way from deployment, scaling and up to provisioning of compute resources. By running applications on such a platform, developers can now focus more on making new features and building new apps and less on provisioning.

Operations can focus more on operating a stable platform and will deal less with provisioning of code.

4. Faster time to market

From a brilliant whiteboard idea to market release, companies struggling with legacy infrastructure will necessary stumble upon some obstacles on the way. What should be a quick release for hitting that new market trend, results in delays and sometimes no release at all. This while competition is already out with their brand new solutions, helping themselves to new customers.

Having applications running as microservices, you can quickly change and switch entire parts of you application stack without affecting other services. A container is as easy to start as it is to kill off and replace, having a split architecture through container platforms will therefore accelerate faster deployment to your customers.

In summary, there is no doubt that containers and PaaS is the way forward, and as all major Cloud Providers have container platforms as a service, making it easier to move over to PaaS one microservice at a time.Redpill Linpro can help you with your PaaS strategy, both with choosing the correct platform, planning, migration and optimisation.

More to explore

We have expertise in container platforms on both AWS and Open Source, and offer our own Redpill Linpro Nordic Cloud Container Platform with guaranteed data storage in Norway.

Contact

Mia Ryan
Sales Advisor at Redpill Linpro
Contact

Containers 101

Mon, 12 Apr 2021 00:00:00 +0000

Container driven development is catching on like wildfire, and for good reasons. In the age of digital transformation, time to market is becoming a competitive edge impossible to ignore. To be able to speed up the software development and deployment, monolithic application development sooner or later will be extinct.

Other factors that drive the world towards containers are microservice architecture, continuous integration and delivery (CI/CD), DevOps bringing dev and ops closer together and cloud computing with multi infrastructure portability. More on that later, in this text we’ll focus on the container technology basics.

The basics

In a traditional application world, an application requires code, runtime, system tools, system libraries and settings. In a container, the application code is encapsulated together with all those building blocks it needs to run.

Why would you choose to do that?

Mostly because presenting a consistent software environment as a container makes it a lot easier for the application to go from the developer’s desktop to testing to production deployment.

There is simply no more need to make sure all libraries and settings in production are corresponding to the ones used in development, dramatically reducing the time and effort required for releasing new code.

Containers also isolate the application from its surroundings, both reducing conflicts between different applications on the same infrastructure and minimizing application issues to a single container instead of the entire infrastructure.

When updating the application code, a new container is build to replace the old container. When deploying the new container into production, the old container is simply thrown away. This is a good reason why a container should be stateless, that is; no state or data should be stored within it, as the data would be lost when the container is replaced.

Container architecture

Container technology isn’t really new; Linux containers (LXC) have been around for about 10 years. Yet first when a standard way to divide applications into containers was established, a major breakthrough was made.

There are other suppliers involved, but no one disputes that Docker has led the charge and sits at the heart of the market. Docker revolutionized container adaption by providing a container standard and thereby making it easy for developers to build and run their containers.

By fundamentally changing the way developers build applications, Docker became one of the most popular open source projects in history.

As well as holding the container standard, Docker also provides operations to start, stop and build containers.

Container orchestration

Unless handled with care, running containers includes a risk of ending up herding cats. To avoid this, software has been written to handle containers beyond starting and stopping. The ability to automatecontainer management is one of the prime benefits of container based applications.

This brings on container orchestration. Orchestration is where much of the current innovation lies in the container technology ecosystem and where the competition is heating up most.

Tools like Docker Compose provide basic support for defining simple multi-container applications. However, full orchestration involves more complicated tasks like scheduling of how and when containers should run, continuous deployment (CD), cluster management and provisioning of extra resources, possibly across multiple hosts.

Kubernetes, backed by Google, is currently the most popular container orchestration tool. Other container orchestration tools include Docker Swarm and Apache Mesos.

Container platforms: Platform as a Service (PaaS)

Container based applications comes with the ability to run on a variety of different physical and virtual machines, in the cloud or not. PaaS is a general term for a cloud computing service that provides a platform for users to easily develop, run, and manage applications in a cloud.

When offering PaaS, Cloud providers offers infrastructure, servers, networking, storage, database, operating system (OS), security, runtime environment and infrastructure monitoring all in one. Abstracting all those lower infrastructure layers, developers only needs to bring their containers and application data.

PaaS simply enables developers to concentrate on what they do best; coding, as well as empowering them to manage their application without regards to lower infrastructure.

Say you want to move an application from one cloud platform to another, or implement automatic scaling and restarting applications. PaaS solutions offers flexibility, workload management advantages and provides the ability to easily set up fault-tolerant systems.

Well known PaaS includes AWS Elastic Beanstalk, Google App Engine and RedHat OpenShift.

Contact

Margrethe Monsen
Managing Director at Redpill Linpro
Contact

Finalizing the VPC template

Wed, 31 Mar 2021 00:00:00 +0000

I want to wrap up the VPC template from the previous blog entry “Moving forward with Cloudformation templates”

What we ended up with there was a VPC with a Private and a Public Subnet in 3 Availability Zones.

Now I want to start to use the Outputs section of the template.

And when that has been introduced, I want to use Nested Stacks

Why Outputs?

When we create a VPC with the template from the last blog, we get a VPC, but information about that stack is lost on us. You need to query for all VPC to find the VPC, need to search for subnets to be able to use them.

With Outputs, you can query the Stack it self to get information about the resources it creates.

Real example

I have the template from last blog stored in a file called blogvpc.yaml, then I create a stack with it.

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation create-stack --stack-name forblog --template-body file://blogvpc.yaml
{
  "StackId":"arn:aws:cloudformation:eu-west-2:123NaN123201:stack/forblog/ef5b8d00-91fd-11eb-b513-06c721e1f154"
}

When it was done, I could see the result:

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name forblog  --template-body file://blogvpc.yaml
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/forblog/ef5b8d00-91fd-11eb-b513-06c721e1f154",
            "StackName": "forblog",
            "Description": "This is an attempt to create a VPC in a Cloudformation stack",
            "CreationTime": "2021-03-31T08:48:59.519Z",
            "RollbackConfiguration": {},
            "StackStatus": "CREATE_COMPLETE",
            "DisableRollback": false,
            "NotificationARNs": [],
            "Tags": [],
            "EnableTerminationProtection": false,
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

As you can see there is not a lot of useful information in this output.

Yes, I can run some other commands, for digging into the Stack.

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stack-resources --stack-name forblog
{
    "StackResources": [
        {
            "StackName": "forblog",
            "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/forblog/ef5b8d00-91fd-11eb-b513-06c721e1f154",
            "LogicalResourceId": "GatewayToInternet",
            "PhysicalResourceId": "forbl-Gatew-1ILE8XW7D3OMG",
            "ResourceType": "AWS::EC2::VPCGatewayAttachment",
            "Timestamp": "2021-03-31T08:49:36.433Z",
            "ResourceStatus": "CREATE_COMPLETE",
            "DriftInformation": {
                "StackResourceDriftStatus": "NOT_CHECKED"
            }
        },
....

But that gives me all the resources, and is tedious to format queries to grep out the parts that I need, most of the resources are elements I do not want to know about.

Adding Outputs

I write plural of Outputs as that is the name of the section in Cloudformation, but we start with adding only 1.

To our existing template, we add the following at the end.

Outputs:
  VPCid:
    Description: The VPCid
    Value: !Ref VPC

And then run an update of the stack

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation update-stack --stack-name forblog --template-body file://blogvpc.yaml
{
  "StackId":"arn:aws:cloudformation:eu-west-2:123NaN123201:stack/forblog/ef5b8d00-91fd-11eb-b513-06c721e1f154"
}

Then I can check for the new description

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name forblog
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/forblog/ef5b8d00-91fd-11eb-b513-06c721e1f154",
            "StackName": "forblog",
            "Description": "This is an attempt to create a VPC in a Cloudformation stack",
            "CreationTime": "2021-03-31T08:48:59.519Z",
            "LastUpdatedTime": "2021-03-31T09:20:15.381Z",
            "RollbackConfiguration": {},
            "StackStatus": "UPDATE_COMPLETE",
            "DisableRollback": false,
            "NotificationARNs": [],
            "Outputs": [
                {
                    "OutputKey": "VPCid",
                    "OutputValue": "vpc-085967d5f0b867c95",
                    "Description": "The VPCid"
                }
            ],
            "Tags": [],
            "EnableTerminationProtection": false,
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

Only the parts we choose to output will be visible there. But now we will turn the output to something useful.

Adding export

We can export values from a stack to use it in another stack, we just need to add an Export: part to the Outputs statements we want to export.

But as we do not get that far on VPCid alone we add export for a Private Subnet as well.

So I change the Outputs part to this:

Outputs:
  VPCid:
    Description: The VPCid
    Value: !Ref VPC
    Export:
      Name: BlogVpc
  PrivateSubnet0:
    Description: A subnet
    Value: !Ref PrivateSubnet0
    Export:
      Name: PrivateSubnet0

and update the stack, and then check for the description I get:

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name forblog
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/forblog/ef5b8d00-91fd-11eb-b513-06c721e1f154",
            "StackName": "forblog",
            "Description": "This is an attempt to create a VPC in a Cloudformation stack",
            "CreationTime": "2021-03-31T08:48:59.519Z",
            "LastUpdatedTime": "2021-03-31T10:47:07.379Z",
            "RollbackConfiguration": {},
            "StackStatus": "UPDATE_COMPLETE",
            "DisableRollback": false,
            "NotificationARNs": [],
            "Outputs": [
                {
                    "OutputKey": "PrivateSubnet0",
                    "OutputValue": "subnet-0bd91e942916edd41",
                    "Description": "A subnet",
                    "ExportName": "PrivateSubnet0"
                },
                {
                    "OutputKey": "VPCid",
                    "OutputValue": "vpc-085967d5f0b867c95",
                    "Description": "The VPCid",
                    "ExportName": "BlogVpc"
                }
            ],
            "Tags": [],
            "EnableTerminationProtection": false,
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

This change does not look like something to write home about, but actually, now we can use the resources from this stack in another.

Using the export in another template

Let us create a template called avm.yaml that starts an EC2 instance in our VPC.

---
Description: A silly template for using Export

Parameters:

  AMI:
    Type: AWS::EC2::Image::Id

Resources:

  TheVM:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref AMI
      InstanceType: t3.micro
      SubnetId:
        Fn::ImportValue: PrivateSubnet0

Outputs:
  TheVMid:
    Description: ID of the VM
    Value: !Ref TheVM

The newest AMI for Ubuntu 18.04 in eu-west-2 is, when I write this, ami-066213f162acbccdc so I use that when I create the stack:

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation create-stack --stack-name thevm --template-body file://avm.yaml --parameters ParameterKey=AMI,ParameterValue=ami-066213f162acbccdc
{
  "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/thevm/233c51a0-921b-11eb-b3b7-024fe784c338"
}

And then when we get description of the stack, we get the ID of an instance.

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name thevm
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/thevm/233c51a0-921b-11eb-b3b7-024fe784c338",
            "StackName": "thevm",
            "Description": "A silly template for using Export",
            "Parameters": [
                {
                    "ParameterKey": "AMI",
                    "ParameterValue": "ami-066213f162acbccdc"
                }
            ],
            "CreationTime": "2021-03-31T12:18:01.855Z",
            "RollbackConfiguration": {},
            "StackStatus": "CREATE_COMPLETE",
            "DisableRollback": false,
            "NotificationARNs": [],
            "Outputs": [
                {
                    "OutputKey": "TheVMid",
                    "OutputValue": "i-0c6c58bb36a3e4afc",
                    "Description": "ID of the VM"
                }
            ],
            "Tags": [],
            "EnableTerminationProtection": false,
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

Cleanup

And then a cleanup:

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation delete-stack --stack-name thevm

Checking for if the stack has been removed:

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name thevm

An error occurred (ValidationError) when calling the DescribeStacks operation: Stack with id thevm does not exist

It is gone, so now I remove the VPC stack.

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation delete-stack --stack-name forblog

Things to note about Exports

Uniqueness of the Name

The ExportName is unique in a region for your account. I find it useful to prefix the exports with a value so two stacks from the same template can coexist in the same region. So you have the same templates for stage environments as the production environments.

More about this below.

Locking of resources

Resources that you export can not be replaced or deleted. Cloudformation will protest if you try to change your stack with that result. See here

Nesting

That was the Export part, let us look at Nesting next.

Why nesting

With nesting, you can start stacks from a parent stack. Doing that allows you to reuse templates. I will now rewrite the VPC template from previous blog to use that. And by that reduce the repetition significantly.

The nested stack templates must exist in S3 and be readable for the account that creates the stack. Actually, if you create a stack from a local file, the AWS cli just copies your template to an S3 bucket it creates for that purpose.

The Parent stack.

The complete stack is available here

Let us just dive in and take a look at it

Description and Parameters

I like having a link to the template in the description together with a description of what the templates implements

The parameters have sane default values, so you do not need to pass any when you start the stack. But there is the ExportPrefix which can be used if you are starting many different stacks from the same template.

---
Description: Template for simple VPC, 9 subnets in 3 AZ, IPv4 only. Url for template, https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.nested.yaml

Parameters:
  SecondOctet:
    Description: The X in your 10.X.0.0/16 VPC
    Type: Number
    MinValue: 0
    MaxValue: 255
    Default: 42
  ExportPrefix:
    Type: String
    Description: Custom prefix for exported values. Can be empty
    AllowedPattern: ^[a-zA-Z0-9-_]*$
    ConstraintDescription: '^[a-zA-Z0-9-_]'
    MaxLength: '28'
    MinLength: '0'
    Default: vpc-
  Owner:
    Description: Name of owner of the resource
    Type: String
    Default: Techblog

Basic Resources

Here we define the VPC, Internet Gateway and routing tables, the usual stuff. Everything that is not Availability Zone specific

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      EnableDnsSupport: true
      EnableDnsHostnames: true
      CidrBlock: !Sub 10.${SecondOctet}.0.0/16
      Tags:
        - Key: owner
          Value: !Ref Owner
        - Key: StackDescription
          Value: !Ref 'AWS::StackName'
        - Key: Network
          Value: Public
        - Key: Name
          Value: !Sub ${AWS::StackName} - VPC

  InternetGW:
    Type: AWS::EC2::InternetGateway

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

  RouteTablePublic:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: owner
          Value: !Ref Owner
        - Key: Name
          Value: !Sub ${AWS::StackName} - Route Table Public
  RoutePublicIPv4:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePublic
      GatewayId: !Ref InternetGW

  RouteTablePrivate:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: owner
          Value: !Ref Owner
        - Key: Name
          Value: !Sub ${AWS::StackName} - Route Table Private

Subnets

And here comes the special part, when defining the subnets, we define stacks for each of the Availability Zones, and those define resources specific for the Availability Zone.

We need to send some parameters to the stacks, but the only thing that differs between the stacks is the AZ parameter, which is used to denote the Availability Zone.

  SubnetsAZa:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.az.yaml
      Parameters:
        SecondOctet: !Ref SecondOctet
        ExportPrefix: !Ref ExportPrefix
        Owner: !Ref Owner
        AZ: 0
        VPC: !Ref VPC
        RouteTablePublic: !Ref RouteTablePublic
        RouteTablePrivate: !Ref RouteTablePrivate
  SubnetsAZb:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.az.yaml
      Parameters:
        SecondOctet: !Ref SecondOctet
        ExportPrefix: !Ref ExportPrefix
        Owner: !Ref Owner
        AZ: 1
        VPC: !Ref VPC
        RouteTablePublic: !Ref RouteTablePublic
        RouteTablePrivate: !Ref RouteTablePrivate
  SubnetsAZc:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.az.yaml
      Parameters:
        SecondOctet: !Ref SecondOctet
        ExportPrefix: !Ref ExportPrefix
        Owner: !Ref Owner
        AZ: 2
        VPC: !Ref VPC
        RouteTablePublic: !Ref RouteTablePublic
        RouteTablePrivate: !Ref RouteTablePrivate

Outputs

This stack only outputs and exports resources that are not Availability Zone specific.

Outputs:
  VPCid:
    Description: The VPCid
    Value: !Ref VPC
    Export:
      Name: !Sub ${ExportPrefix}VPCid
  VPCidr:
    Description: The VPC IPv4 Subnet
    Value: !GetAtt VPC.CidrBlock
    Export:
      Name: !Sub ${ExportPrefix}VPCidr
  RouteTablePublic:
    Description: Route Table for the Public Subnets
    Value: !Ref RouteTablePrivate
    Export:
      Name: !Sub ${ExportPrefix}RouteTablePublic
  RouteTablePrivate:
    Description: Route Table for the Private Subnets
    Value: !Ref RouteTablePrivate
    Export:
      Name: !Sub ${ExportPrefix}RouteTablePrivate

The child stacks

Description and Parameters

As in the parent template here us a link to the template in the description together with a description of what the templates implements

The parameters here have their values to passed by the parent stack.

---
Description: Template for subnets in an Availability Zone VPC, IPv4 only. Url for template, https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.az.yaml

Parameters:
  SecondOctet:
    Description: The X in your 10.X.0.0/16 VPC
    Type: Number
    MinValue: 0
    MaxValue: 255
  ExportPrefix:
    Type: String
    Description: Custom prefix for exported values. Can be empty
    AllowedPattern: ^[a-zA-Z0-9-_]*$
    ConstraintDescription: '^[a-zA-Z0-9-_]'
    MaxLength: '28'
    MinLength: '0'
  Owner:
    Description: Name of owner of the resource
    Type: String
  AZ:
    Description: The number of the AZ the resource should be in, 0 - 2 for 3 AZ
    Type: Number
    MinValue: 0
    MaxValue: 2
  VPC:
    Description: The VPC this AZ belongs to
    Type: AWS::EC2::VPC::Id
  RouteTablePublic:
    Description: The route table for the Public Subnet
    Type: String
  RouteTablePrivate:
    Description: The route table for the Private Subnet
    Type: String

The Subnets

Here we define the 3 types of subnets we have in each Availability Zone. One Public Subnet, one Private Subnet behind NAT gateway, and a Private Subnet without access to Internet.

I use the Availability Zone number in the definition of of the CIDR for the subnet.

Resources:

  PublicSubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone:
        Fn::Select:
          - !Ref AZ
          - Fn::GetAZs: ""
      CidrBlock: !Sub 10.${SecondOctet}.${AZ}.0/24
      MapPublicIpOnLaunch: true
      Tags:
        - Key: owner
          Value: !Ref Owner
        - Key: StackDescription
          Value: !Ref 'AWS::StackName'
        - Key: Network
          Value: Public
        - Key: Name
          Value: !Sub ${ExportPrefix}PublicSubnet-${AZ}
  PrivateSubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone:
        Fn::Select:
          - !Ref AZ
          - Fn::GetAZs: ""
      CidrBlock: !Sub 10.${SecondOctet}.1${AZ}.0/24
      Tags:
        - Key: owner
          Value: !Ref Owner
        - Key: StackDescription
          Value: !Ref 'AWS::StackName'
        - Key: Network
          Value: Private
        - Key: Name
          Value: !Sub ${ExportPrefix}PrivateSubnet-${AZ}

  PrivateNATSubnet:
    Type: 'AWS::EC2::Subnet'
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone:
        Fn::Select:
          - !Ref AZ
          - Fn::GetAZs: ""
      CidrBlock: !Sub 10.${SecondOctet}.2${AZ}.0/24
      Tags:
        - Key: owner
          Value: !Ref Owner
        - Key: StackDescription
          Value: !Ref 'AWS::StackName'
        - Key: Network
          Value: Private
        - Key: Name
          Value: !Sub ${ExportPrefix}PrivateNATSubnet-${AZ}

NAT Gateway and route table

There is a NAT Gateway in each Availability Zone. And it has its own route table.

  NatGWIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

  NatGW:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGWIP.AllocationId
      SubnetId: !Ref PublicSubnet
      Tags:
        - Key: owner
          Value: !Ref Owner

  RouteTableNATPrivate:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: owner
          Value: !Ref Owner

  RoutePrivateNATIPv4:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTableNATPrivate
      NatGatewayId: !Ref NatGW

Associating the subnets and route tables

That needs to be done for each subnet. The isolated Private Subnet uses a Route Table that was created in the parent stack and sent as a Parameter. Same for the Public Subnet. There is a unique Route Table for each NAT’ed subnet as they have their own NAT gateway.

  Route2SubnetPublicIPv4:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref PublicSubnet

  Route2SubnetPrivateNATIPv4:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTableNATPrivate
      SubnetId: !Ref PrivateNATSubnet



  Route2SubnetPrivateIPv4:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePrivate
      SubnetId: !Ref PrivateSubnet

Outputs

Here we export the Subnets for the Availability Zone and the Route Table for the NAT Gateway. Remember that the ExportName needs to be unique, so I prefix it with the ExportPrefix Parameter, and postfix with the number of the Availability Zone in the AZ Parameter.

Outputs:
  PublicSubnet:
    Description: Public Subnet
    Value: !Ref PublicSubnet
    Export:
      Name: !Sub ${ExportPrefix}PublicSubnetAZ${AZ}

  PrivateSubnet:
    Description: Private Subnet
    Value: !Ref PrivateSubnet
    Export:
      Name: !Sub ${ExportPrefix}PrivateSubnetAZ${AZ}
  PrivateNATSubnet:
    Description: Private NAT Subnet
    Value: !Ref PrivateNATSubnet
    Export:
      Name: !Sub ${ExportPrefix}PrivateNATSubnetAZ${AZ}

  RouteTableNATPrivate:
    Description: Route Table for Private NAT Subnet
    Value: !Ref RouteTableNATPrivate
    Export:
      Name: !Sub ${ExportPrefix}RouteTableNATPrivateAZ${AZ}

Take it for a spin…

We create a single stack from the parent template by running

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation create-stack --stack-name nested-blog --template-url https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.nested.yaml
{
    "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog/edb4d580-9237-11eb-9a54-0a355b7dff20"
}

Then after quite some while we can look at the stack

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name nested-blog
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog/edb4d580-9237-11eb-9a54-0a355b7dff20",
            "StackName": "nested-blog",
            "Description": "Template for simple VPC, 9 subnets in 3 AZ, IPv4 only. Url for template, https://s3.eu-central-1.amazonaws.com/templates.bitbit/techblog/vpc.nested.yaml",
            "Parameters": [
                {
                    "ParameterKey": "Owner",
                    "ParameterValue": "Techblog"
                },
                {
                    "ParameterKey": "ExportPrefix",
                    "ParameterValue": "vpc-"
                },
                {
                    "ParameterKey": "SecondOctet",
                    "ParameterValue": "42"
                }
            ],
            "CreationTime": "2021-03-31T15:44:07.614Z",
            "RollbackConfiguration": {},
            "StackStatus": "CREATE_COMPLETE",
            "DisableRollback": false,
            "NotificationARNs": [],
            "Outputs": [
                {
                    "OutputKey": "RouteTablePrivate",
                    "OutputValue": "rtb-0ad3e61a075aeea7c",
                    "Description": "Route Table for the Private Subnets",
                    "ExportName": "vpc-RouteTablePrivate"
                },
                {
                    "OutputKey": "VPCid",
                    "OutputValue": "vpc-05e40be58b0da76cc",
                    "Description": "The VPCid",
                    "ExportName": "vpc-VPCid"
                },
                {
                    "OutputKey": "VPCidr",
                    "OutputValue": "10.42.0.0/16",
                    "Description": "The VPC IPv4 Subnet",
                    "ExportName": "vpc-VPCidr"
                },
                {
                    "OutputKey": "RouteTablePublic",
                    "OutputValue": "rtb-0ad3e61a075aeea7c",
                    "Description": "Route Table for the Public Subnets",
                    "ExportName": "vpc-RouteTablePublic"
                }
            ],
            "Tags": [],
            "EnableTerminationProtection": false,
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

That does not show us the Subnet stacks, but we can ask Cloudformation for all exports, and get a long list, I include it here for fun and profit.

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation list-exports
{
    "Exports": [
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZa-1S3IELV5150CM/fcf7d8d0-9237-11eb-a30a-0a953df5d268",
            "Name": "vpc-PrivateNATSubnetAZ0",
            "Value": "subnet-0fa4f57de3e503ff2"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZb-8ULH4BH3LOQ6/fcf4a480-9237-11eb-b513-06c721e1f154",
            "Name": "vpc-PrivateNATSubnetAZ1",
            "Value": "subnet-027efcf30c5209d95"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZc-1N9U05AXMUP8V/fce11c80-9237-11eb-93ff-022e9396137a",
            "Name": "vpc-PrivateNATSubnetAZ2",
            "Value": "subnet-00ef014554daa6ccc"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZa-1S3IELV5150CM/fcf7d8d0-9237-11eb-a30a-0a953df5d268",
            "Name": "vpc-PrivateSubnetAZ0",
            "Value": "subnet-0a1ad9437c884b157"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZb-8ULH4BH3LOQ6/fcf4a480-9237-11eb-b513-06c721e1f154",
            "Name": "vpc-PrivateSubnetAZ1",
            "Value": "subnet-025a179fe5b3820f8"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZc-1N9U05AXMUP8V/fce11c80-9237-11eb-93ff-022e9396137a",
            "Name": "vpc-PrivateSubnetAZ2",
            "Value": "subnet-07d004eb9c1192773"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZa-1S3IELV5150CM/fcf7d8d0-9237-11eb-a30a-0a953df5d268",
            "Name": "vpc-PublicSubnetAZ0",
            "Value": "subnet-017edbd14176b6c02"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZb-8ULH4BH3LOQ6/fcf4a480-9237-11eb-b513-06c721e1f154",
            "Name": "vpc-PublicSubnetAZ1",
            "Value": "subnet-03460753b66112c9f"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZc-1N9U05AXMUP8V/fce11c80-9237-11eb-93ff-022e9396137a",
            "Name": "vpc-PublicSubnetAZ2",
            "Value": "subnet-062419d50a7aa907c"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZa-1S3IELV5150CM/fcf7d8d0-9237-11eb-a30a-0a953df5d268",
            "Name": "vpc-RouteTableNATPrivateAZ0",
            "Value": "rtb-0ea59402ad6fb359b"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZb-8ULH4BH3LOQ6/fcf4a480-9237-11eb-b513-06c721e1f154",
            "Name": "vpc-RouteTableNATPrivateAZ1",
            "Value": "rtb-096736e362d8009b4"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog-SubnetsAZc-1N9U05AXMUP8V/fce11c80-9237-11eb-93ff-022e9396137a",
            "Name": "vpc-RouteTableNATPrivateAZ2",
            "Value": "rtb-0f044d02cd62dbf41"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog/edb4d580-9237-11eb-9a54-0a355b7dff20",
            "Name": "vpc-RouteTablePrivate",
            "Value": "rtb-0ad3e61a075aeea7c"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog/edb4d580-9237-11eb-9a54-0a355b7dff20",
            "Name": "vpc-RouteTablePublic",
            "Value": "rtb-0ad3e61a075aeea7c"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog/edb4d580-9237-11eb-9a54-0a355b7dff20",
            "Name": "vpc-VPCid",
            "Value": "vpc-05e40be58b0da76cc"
        },
        {
            "ExportingStackId": "arn:aws:cloudformation:eu-west-2:123NaN123201:stack/nested-blog/edb4d580-9237-11eb-9a54-0a355b7dff20",
            "Name": "vpc-VPCidr",
            "Value": "10.42.0.0/16"
        }
    ]
}

We can get the short version of that by using the --query argument

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation list-exports --query Exports[].Name
[
    "vpc-PrivateNATSubnetAZ0",
    "vpc-PrivateNATSubnetAZ1",
    "vpc-PrivateNATSubnetAZ2",
    "vpc-PrivateSubnetAZ0",
    "vpc-PrivateSubnetAZ1",
    "vpc-PrivateSubnetAZ2",
    "vpc-PublicSubnetAZ0",
    "vpc-PublicSubnetAZ1",
    "vpc-PublicSubnetAZ2",
    "vpc-RouteTableNATPrivateAZ0",
    "vpc-RouteTableNATPrivateAZ1",
    "vpc-RouteTableNATPrivateAZ2",
    "vpc-RouteTablePrivate",
    "vpc-RouteTablePublic",
    "vpc-VPCid",
    "vpc-VPCidr"
]

Clean up afterwards.

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation delete-stack --stack-name nested-blog

This will remove the child stacks and then the parent stack.

Now the VPC stack is out of the way, and next time I can describe templates defining something more interesting than a VPC.

Video conferencing and privacy, findings and conclusion

Wed, 24 Mar 2021 00:00:00 +0000

In our prevous blog post, we described how to tackle the challenge of choosing the right video conferencing solution and describe a methodology. In this post we will let you in on our findings and conclusions.

Findings - part 1

To start, a very interesting observation is that none of the well-known and most used video conferencing solutions did make it beyond the first part of the review. This means that legal requirements for processing of personal data were not met in an adequate manner. This is inasmuch surprising, as the agreements otherwise appear quite sound and worked out.

The review identified several shortcomings which roughly can be grouped into the following categories.

1. Inadequate data processing agreements

The DPA does not fulfil relevant requirements in the GDPR such as restricting the data controllers authority to give directions on data processing, or the agreement restricts rights or obligations which are not compatible with GDPR. It might also be the case that necessary safeguards are not in place, or not satisfactory.

2. Unlawful data transfer or processing

3. Accountability of the controller is constrained

Some agreements include clauses that allow for unilateral and unannounced changes of the agreement, which makes it impossible for the controller to fulfil their accountability requirements. This is also often the case where sub-processors are involved where the list of sub processors can be updated without further notice.

4. Data processing for other purposes

Some providers reserve the right to process data for their own, or third parties, purposes which is not acceptable

The review contains also detailed information about the findings, and reasoning for why an agreement was deemed inadequate with regards to the GDPR.

Findings - part 2

For the second part, the remaining services where reviewed on data security and how the technical solution supports data privacy in their default configuration. The assessment is based on several criteria like encryption, authentication for participants and the meeting host, but also privacy requirements like unauthorised or unannounced recording possibilities. A detailed description of these requirements can be found in chapter 4.

Further, a set of three use cases have been defined, with varying degrees of privacy and security requirements. The different video conferencing solutions have been assessed on how well they fulfil the security and privacy requirements on the background of these use cases.

Basically, the use cases are ranged from low to high requirements on privacy, based on the nature of the discussed topic as well as the protection requirements of all participants.

The review did only find three categories of shortcomings preventing a positive rating:

1. No mandatory authentication of participants with for example a username and password

2. No role-based access control (RBAC)

3. Camera/microphone cannot be deactivated by default when entering the conference

Another evaluated criteria is the quality of end-to-end encryption, where the review differentiates between weak and strong end-to-end encryption. The difference is that for strong end-to-end encryption, the encryption keys are negotiated for each session between the end devices, and the encryption keys are not available to the provider. Weak end-to-end encryption on the other hand only prevents from casual observation by the provider (as encryption keys are available to the provider).

All video conferencing solutions reviewed in this part did at least pass the requirements for the least-demanding use case, and most did also provide enough protection for conferences with high demands on privacy and security.

End-to-end encryption is only available for few of the reviewed solutions.

Jitsi Meet

Redpill Linpros VCaaS solution is based on Jitsi Meet a free and open source video conferencing solution. Jitsi Meet is one of the OSS solutions reviewed in the Berlin note, with quite good results on the technical side - with a few caveats:

1. Jitsi Meet has no role-based access controll

2. Jitsi Meet does not provide a wide range of features for access control

The standard setup of Jitsi Meet is to allow anybody to set up and connect to running video conferences. This is quite convenient in day-to-day use, but will become an issue when hosting large meetings that require confidentiality or privacy. Jitsi Meet does provide two features to handle this: setting passwords on meeting rooms, as well as requiring authentication before being able to create or join a virtual meeting room.

Setting a password that is shared separately from the meeting invitation is certainly a way to increase privacy for meetings with low or moderate requirements, especially for groups that know each other and will guard themselves against unknown participants.

Some of the use cases described in the review have higher demands on confidentiality and privacy, and the Berlin note recommends to use RBAC and individual authentication in these cases. This is also recommended when hosting video conferences participants that do not know each other personally, where privacy requirements are relevant.

Conclusions

It was quite surprising to find that almost all of the well-known video conferencing solutions (like Zoom, Teams, Webex, Gotomeeting or Skype) do not provide a service with a data privacy agreement conforming to European law. There are exceptions, and the review lists several solutions that do conform to legal requirements as well as provide secure and private solutions.

All services that did pass the legal requirements did also pass the security and privacy requirements, at least for the least-demanding use case outlined in the review. Three video conferencing solutions did pass all requirements, and two of these are open source software - including the one with strongest end-to-end encryption.

While not all criteria in this review might be applicable to your specific requirements, this review does provide valuable insight into how to conduct an assessment, and especially the findings of the legal review should be thought-provoking. The review also gives a good overview over video conferencing solutions available.

Contact

Michael Nemecky
Operations Manager at Redpill Linpro
Contact

Video conferencing and privacy, choosing a solution

Wed, 24 Mar 2021 00:00:00 +0000

The last year has been a challenge for most people in Scandinavia and the rest of the world, battling against COVID19 and trying to keep their lives and jobs up and running. But it has also been a year of change, with increased use and acceptance of home working pushing the boundaries for several technologies that support team working and collaboration.

At our workplace, video conferencing has become one of the most used technologies during this year. Despite working in a tech-savvy company, we would seldom use video conferencing on a regular basis before, but more than often we just would walk into our colleagues office and discuss the matter at hand. This, among other things, has drastically changed.

Choosing the right video conferencing system is often about finding a solution that offers the required features, is easy to use and integrate, and, above all, does not cost a fortune. The privacy aspects are more than often overlooked, especially when everybody just “needs to get this running”, as was the case in the early days of COVID.

The challenge

A lot of meetings that would have been a private chat between two colleagues in an office have moved to video. Almost everybody would have the presence of mind to close the door to their office or meeting room when discussing sensitive matters, or matters that require more privacy. This might not be the case for a video conference, or any other online conversation, for that matter.

The challenge arises from the fact that while tools like video conferencing try to make anybody feel like they are just a (sophisticated) extension of the physical world, in reality your private conversation might travel around the world and use services you never knew about.

Choosing a solution

The legal and security aspects should be assessed together with the functional aspects when choosing a video conferencing solution. Video conferencing tools do process personal data, and as such are subject to data privacy laws like the GDPR, as well as other laws and regulations depending on your concrete situation.

In addition, how you plan to use the tools, as well as other requirements like confidentiality or integrity, contractual constraints or company policy will shape whether a specific video conferencing solution will fit or not.

The Data Security Officer for Berlin, Germany, Maja Smoltczyk has released a note on the use of video conference solutions that might be helpful in assessing the different offerings available on the market:

For the press release
For the review

While the note primarily is targeted at public offices in Berlin, the observations and general conclusions are valid for anyone using video conferencing. The approach described in the note can also be used as a blueprint for own reviews of tools.

Methodology

The review consists of two steps:

The lawfulness of the data processing agreement with the provider is verified, based on publicly available information provided. Also, a cursory check is conducted whether all sub-providers in use are listed in the agreement
A check to identify which security measures for authentication, authorization and encryption are provided “out of the box”, i.e. without any adjustments

When a solution was deemed unsatisfactory during one step, the remaining steps were not conducted in this review, and not all solutions have therefore been reviewed for their security measures, for example. Also, the review is based on the publicly available agreement for the solutions reviewed, and does not take into account that other agreements can be negotiated.

Still, the review gives a good overview over the current state, and what details to focus on when reviewing data privacy agreements.

We will reveal our findings and conclusions in the next blog post:

Video conferencing and privacy - findings and conclusions.

Contact

Michael Nemecky
Operations Manager at Redpill Linpro
Contact

Moving forward with Cloudformation templates

Fri, 27 Nov 2020 00:00:00 +0000

Now we continue improving the VPC template from my previous blog entry “Starting with Cloudformation templates”

What we ended up with there was a VPC with one subnet connected to the Internet. Or what is know in AWS lingo as a “Public Subnet”.

The goal now is a VPC with presence in tree Availability Zones with a “Public Subnet” in each, and a “Private Subnet” in each as well.

Humble beginnings

Before we go all out on tree Availability Zones, let us set it up with only one. It will not be that hard to expand the template to tree Availability Zones when we have got it up and running on one.

Public vs Private subnet

The main difference between a Private and a Public subnet is its routing to Internet.

Public subnet

The Public subnet is routed directly through an Internet Gateway so you need an Elastic IP on a resource accessing Internet. Resources can then also be available on the Internet through their Elastic IP.

Private subnet

The Private subnet does not have direct route to Internet, and can be configured in a manner it does not have access to Internet at all. We will allow access to the Internet through a NAT Gateway. Resources in a Private subnet have no use of Elastic IP.

NAT Gateway

The NAT Gateway we talk about here is a managed service from AWS, and it comes with a price. Each instance of NAT Gateway costs $0.045 per hour and $0.045 per GB data transferred in or out. In our setup with tree Availability Zones and a NAT Gateway in each of them, we get up to $100 a month just for the Gateways alone.

You can read more about NAT Gateway pricing here

Private Subnet in Cloudformation

As stated, the main difference is in the routing. And we know we need a NAT Gateway, let us check the documentation.

It gives us this skeleton:

Type: AWS::EC2::NatGateway
Properties:
  AllocationId: String
  SubnetId: String
    Tags:
      - Tag

Both SubnetId and AllocationId are required. SubnetId needs a reference to a AWS::EC2::Subnet resource. But AllocationId is The allocation ID of an Elastic IP address to associate with the NAT gateway.

So we check the documentation for Elastic IP and it gives us

Type: AWS::EC2::EIP
Properties:
  Domain: String
  InstanceId: String
  PublicIpv4Pool: String
  Tags:
    - Tag

Of those, only Domain is of interest, and as it is to be used with a NAT Gateway we not care for EC2-Classic, so we set this to vpc.

The documentation also mentions that if we are creating this resource in the same template as our VPC we need to create dependency on the VPC-gateway attachment.

A very important thing we can read from the documentation page is the return values of the resource. If you ask for the !Ref value, you will get the IP address associated with the resource, but we want the allocation ID of it.

To access that value we need to use the Fn::GetAtt function. And we need to use it with the AllocationId key word. Look for that below. There we use the shorter !GetAtt form of the function.

Dependency

You can give Cloudformation directions on order it must create resources. You can do that by using the keyword DependsOn. Like for example:

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

  NatGWIP:
    DependsOn: GatewayToInternet
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

You do not need to specify the DependsOn relationship if the dependency is show through reference as seen here:

  InternetGW:
    Type: AWS::EC2::InternetGateway

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

Here it would be superfluous to declare that GatewayToInternet was dependent on InternetGW. You can read more about DependsOn here

How a subnet is defined

Now we need to look back to a normal subnet and see what is needed to define it and its routing. The parts from my previous blog are:

  SubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.42.0/24
      VpcId: !Ref VPC

  RouteTablePublic:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RoutePublic:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePublic
      GatewayId: !Ref InternetGW

  Route2Subnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref SubNett

So there is a route, in a route table. Then there is a subnet, and then there is the association between subnet and route table.

The difference from this to the Private subnet is where to route the traffic not local to the VPC.

Route for a Private subnet

As we stated in last blog, these are all the options for the Route resource:

Type: AWS::EC2::Route
Properties:
  DestinationCidrBlock: String
  DestinationIpv6CidrBlock: String
  EgressOnlyInternetGatewayId: String
  GatewayId: String
  InstanceId: String
  NatGatewayId: String
  NetworkInterfaceId: String
  RouteTableId: String
  TransitGatewayId: String
  VpcPeeringConnectionId: String

Now, we will not use GatewayId but the NatGatewayId for the Private subnet.

Private Subnet

Putting the parts together, our Private subnet definition becomes:

  PrivateSubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.43.0/24
      VpcId: !Ref VPC

  NatGWIP:
    DependsOn: GatewayToInternet
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

  NatGW:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGWIP.AllocationId
      SubnetId: !Ref PrivateSubNett

  RouteTablePrivate:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RoutePrivate:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePrivate
      NatGatewayId: !Ref NatGW

  Route2PrivateSubnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePrivate
      SubnetId: !Ref PrivateSubNett

Putting the parts together

Now we combine the end product from previous blog and the last part, moving sections around so they are logically grouped together.

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

  InternetGW:
    Type: AWS::EC2::InternetGateway

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

  NatGWIP:
    DependsOn: GatewayToInternet
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

  NatGW:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGWIP.AllocationId
      SubnetId: !Ref PrivateSubNett

  SubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.42.0/24
      VpcId: !Ref VPC

  PrivateSubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.43.0/24
      VpcId: !Ref VPC

  RouteTablePublic:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RouteTablePrivate:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RoutePublic:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePublic
      GatewayId: !Ref InternetGW

  RoutePrivate:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePrivate
      NatGatewayId: !Ref NatGW

  Route2Subnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref SubNett

  Route2PrivateSubnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePrivate
      SubnetId: !Ref PrivateSubNett

This makes up a template that will create a Private and a Public subnet.

More Availability Zones

Above, we did not say anything about the Availability Zone thing were instantiated in. But now we want to create 3 Public subnets and 3 Private subnets, with each Public and Private pair in distinct Availability Zones.

But let us recap quickly what we need to define.

A VPC, only one.
An Internet Gateway, only one.
A VPC Gateway Attachment, only one.
Elastic IPs, three of them, one for each NAT Gateway
NAT Gateways, three of them, one for each Availability Zone.
Subnets, six of them, one Private and one Public for each Availability Zone.
Route Tables, four total, one for the Public subnets, and one for each of the Private subnets
Routes, four total, one for the Public subnets, and one for each of the Private subnets
Subnet Associations, six total, one for each subnet.

So that is a lot of resources that need to be spelled out. And the only thing that we are missing before we start copy’n’paste bonanza is a way to decide which Availability Zone to instantiate our resources.

Specifying the Availability Zone

For specifying the Availability Zone for our resources we use the fact that the AWS::EC2::Subnet resource has a AvailabilityZone parameter that can be set. So if we are to create a subnet in the Stockholm region, we could use the values:

eu-north-1a
eu-north-1b
eu-north-1c

and we would be set.

But what if we want to use the template in Singapore? Then we would have to change those values. So that would be no good.

What we should do is to use the intrinsic function Fn::GetAZs which returns an array of the Availability Zones in a region. If the function only gets empty "" it defaults to the region the template is instantiated in. Then we need to use the intrinsic function Fn::Select to give use the first, the second and the third Availability Zone in the region. (You can read more about these functions here and here)

The !Select function takes an two element array, where the first element is the index that you want, and the second element is the array you want to select from, using the index given.

Combining everything

Let us combine this, but yet break it up in sections for clarity.

VPC and Internet Gateway

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

  InternetGW:
    Type: AWS::EC2::InternetGateway

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

Elastic IP addresses for the NAT Gateways

Here we start on the tedious repetion of similar resources, I postfix the name of all that kind of resources with the number assosiated with the Availability Zone index

  NatGWIP0:
    DependsOn: GatewayToInternet
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

  NatGWIP1:
    DependsOn: GatewayToInternet
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

  NatGWIP2:
    DependsOn: GatewayToInternet
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

All the subnets…

The IP addresses chosen for each subnet is done this way to behave nicely in the next blog entry.

  PublicSubnet0:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.0.0/24
      VpcId: !Ref VPC
      AvailabilityZone:
        !Select
          - 0
          - !GetAZs ""

  PrivateSubnet0:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.100.0/24
      VpcId: !Ref VPC
      AvailabilityZone:
        !Select
          - 0
          - !GetAZs ""

  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.1.0/24
      VpcId: !Ref VPC
      AvailabilityZone:
        !Select
          - 1
          - !GetAZs ""

  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.101.0/24
      VpcId: !Ref VPC
      AvailabilityZone:
        !Select
          - 1
          - !GetAZs ""

  PublicSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.2.0/24
      VpcId: !Ref VPC
      AvailabilityZone:
        !Select
          - 2
          - !GetAZs ""

  PrivateSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.102.0/24
      VpcId: !Ref VPC
      AvailabilityZone:
        !Select
          - 2
          - !GetAZs ""

The NAT Gateways

  NatGW0:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGWIP0.AllocationId
      SubnetId: !Ref PrivateSubnet0

  NatGW1:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGWIP1.AllocationId
      SubnetId: !Ref PrivateSubnet1

  NatGW2:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGWIP2.AllocationId
      SubnetId: !Ref PrivateSubnet2

The Route Tables

  RouteTablePublic:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RouteTablePrivate0:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RouteTablePrivate1:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RouteTablePrivate2:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

The Routes

  RoutePublic:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePublic
      GatewayId: !Ref InternetGW

  RoutePrivate0:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePrivate0
      NatGatewayId: !Ref NatGW0

  RoutePrivate1:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePrivate1
      NatGatewayId: !Ref NatGW1

  RoutePrivate2:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePrivate2
      NatGatewayId: !Ref NatGW2

Association between route tables and subnets

  Route2PublicSubnet0:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref PublicSubnet0

  Route2PrivateSubnet0:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePrivate0
      SubnetId: !Ref PrivateSubnet0

  Route2PublicSubnet1:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref PublicSubnet1

  Route2PrivateSubnet1:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePrivate1
      SubnetId: !Ref PrivateSubnet1

  Route2PublicSubnet2:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref PublicSubnet2

  Route2PrivateSubnet2:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePrivate2
      SubnetId: !Ref PrivateSubnet2

And there is still thing missing here. We need to export references to the resources created here, so that we can use them in other stacks. That and other improvements await in the next chapter.

Starting with Cloudformation templates

Mon, 21 Sep 2020 00:00:00 +0000

This is not the place to tell anyone why Infrastructure as Code is a good idea. For that I can point the potential readers to a blog by my colleague Yngve about that: Why code your infrastructure?

I a short series of blogs, I intend to demonstrate building infrastructure in AWS in steps, where I will be building upon previous entries. Basic knowledge of network and VPC is assumed.

Note that following these instructions can and will incur costs from AWS, those are the sole responsibility of the user, not me.

What is Cloudformation?

Cloudformation is AWS way of doing Infrastructure as Code. The templates can be written in YAML or JSON. We will only look at the YAML format as that is the one that is actually human readable.

Resource for information

The AWS documentation on Cloudformation is outstanding. I do not try to construct anything in AWS without the guidance of the documentation. As a side note, the navigation in the AWS documentation is terrible, use a search engine as DuckDuckGo or Google (the brave might want to try Bing) to find what you are looking for.

The term stack is used a lot here. We call the collection of resources created from the templates a stack.

Anatomy of a template

The template can consists of following sections

Description
Metadata
Parameters
Mappings
Conditions
Resources
Outputs

Of these, only the Resources section is required.

Description

Just a free text that can be used as a description for your stack.

Metadata

You can use the optional Metadata section to include arbitrary JSON or YAML objects that provide details about the template. I have yet to be bothered.

Parameters

Variables to your stack, can be used to build different environments depending on the values. Values of the individual parameters can be defined in an external JSON structure.

Mappings

Used for different sets of values for a specific key. So you can have a list of AMIs for each AWS Region, or set of different EC2 instance types depending on whether the environment should be stage or production.

Conditions

Here you can define boolean variables that can be used as Condition field in the Resources section

Resources

This is the main part. Here all the definition of the environment is done.

Outputs

Here you can define and format values that are easily accessible from querying your stack, and also define values that are exported from your stack and can be imported into other stacks. Each export from a stack needs to have an unique name within a Region (within your AWS account)

Regarding tags

For this write up, I gloss over the usage of tags, in my opinion one can do that in the learning phase, but tags are really useful assets to use. So I would encourage users to spend some time designing a tag regime for their resources, and manage those through Cloudformation.

Starting on your first stack

Let us create a VPC. If you have not done this before, I highly recommend you to start by looking at the AWS documentation at AWS::EC2::VPC

From the section Syntax we get the following YAML code:

Type: AWS::EC2::VPC
Properties:
  CidrBlock: String
  EnableDnsHostnames: Boolean
  EnableDnsSupport: Boolean
  InstanceTenancy: String
  Tags:
    - Tag

If we then read on the Properties section, we see that the only thing that is required is the CidrBlock, so by stripping all other entries from the YAML we end up with this minimal Cloudformation template

Small steps

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

If we save this to a file called vpc.yaml then we can create a VPC with a command like this, given we have a CLI profile called blogg (more about AWS CLI and profiles here :

jonas@pigz:~/bløgg$ aws --profile blogg cloudformation create-stack --stack-name myawesomeVPC --template-body file://vpc.yaml
{
    "StackId": "arn:aws:cloudformation:eu-central-1:123NaN123201:stack/myawesomeVPC/b9fe6cab-9dfc-4839-b5eb-16bed311730c"
}
jonas@pigz:~/bløgg$

After a short while the stack has been created and the VPC has come to existence

jonas@pigz ~/bløgg$ aws --profile blogg cloudformation describe-stacks --stack-name myawesomeVPC
{
    "Stacks": [
        {
            "StackId": "arn:aws:cloudformation:eu-central-1:123NaN123201:stack/myawesomeVPC/b9fe6cab-9dfc-4839-b5eb-16bed311730c",
            "StackName": "myawesomeVPC",
            "Description": "This is an attempt to create a VPC in a Cloudformation stack",
            "CreationTime": "2020-02-30T25:66:42.898Z",
            "RollbackConfiguration": {},
            "StackStatus": "CREATE_COMPLETE",
            "DisableRollback": false,
            "NotificationARNs": [],
            "Tags": [],
            "EnableTerminationProtection": false,
            "DriftInformation": {
                "StackDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

Next step

As this is rather useless as it is, let us add a subnet, we check the documentation on the AWS website and get the following YAML for a subnet definition

Type: AWS::EC2::Subnet
Properties:
  AssignIpv6AddressOnCreation: Boolean
  AvailabilityZone: String
  CidrBlock: String
  Ipv6CidrBlock: String
  MapPublicIpOnLaunch: Boolean
  Tags:
    - Tag
  VpcId: String

The only properties values that must be set are VpcId and CidrBlock. The value of VpcId comes from the Resource created before, and CidrBlock needs to be a CIDR inside the VPC CIDR.

So with that we modify the old yaml structure to

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

  SubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.42.0/24
      VpcId:
        Fn::Ref: VPC

Note that we use the intrinsic function Fn::Ref there. In this case it returns the value of the AWS::EC2::VPC resource, so we do not need to hard code it into the template. Read more about the intrinsic function here

We can then update our first stack to with those changes

jonas@pigz:~/bløgg$ aws --profile blogg cloudformation update-stack --stack-name myawesomeVPC --template-body file://vpc.yaml
{
    "StackId": "arn:aws:cloudformation:eu-central-1:123NaN123201:stack/myawesomeVPC/19cb1c41-b3cb-4a1b-9d75-aef7df5fddb4"
}
jonas@pigz:~/bløgg$

What we would then have is a VPC with a subnet with no access to anything. It could be used for EC2 instances talking to each other, but that would be about all that you could do. In other words, not that useful.

Internet connectivity

So what is needed to have connectivity to the Internet is an Internet Gateway, That is AWS::EC2::InternetGateway in Cloudformation. If we read the documentation for it is only

Type: AWS::EC2::InternetGateway
Properties:
  Tags:
      - Tag

and the Tags element is not required, so let us add that to our template.

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

  SubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.42.0/24
      VpcId:
        Fn::Ref: VPC

  InternetGW:
    Type: AWS::EC2::InternetGateway

But that gateway is not connected to our VPC at all. For that we need VPC Gateway Attachment, which is defined with AWS::EC2::VPCGatewayAttachment and is described in the documentation as

Type: AWS::EC2::VPCGatewayAttachment
Properties:
  InternetGatewayId: String
  VpcId: String
  VpnGatewayId: String

where we must declare one and only one of InternetGatewayId or VpnGatewayId, we are not dealing with a VPN, so our entry is InternetGatewayId. Adding to our main template it becomes

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

  SubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.42.0/24
      VpcId: !Ref VPC

  InternetGW:
    Type: AWS::EC2::InternetGateway

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

Notice that we have now gone over to the short notation of the intrinsic function Fn::Ref which is just !Ref. There is a limitation on the short notation that you can not chain them, but that is a worry for another time.

The subnet that would be managed with this template is one still without Internet connection, as there is no routing there yet.

Routing

We first need a route table, then a route in that route table, and then we need to attach the route table to our subnet. In order, the elements we need are: AWS::EC2::RouteTable, AWS::EC2::Route and AWS::EC2::SubnetRouteTableAssociation

The documentation for those elements gives us

Type: AWS::EC2::RouteTable
Properties:
  Tags:
    - Tag
  VpcId: String

Here, the tags are optional.

Type: AWS::EC2::Route
Properties:
  DestinationCidrBlock: String
  DestinationIpv6CidrBlock: String
  EgressOnlyInternetGatewayId: String
  GatewayId: String
  InstanceId: String
  NatGatewayId: String
  NetworkInterfaceId: String
  RouteTableId: String
  TransitGatewayId: String
  VpcPeeringConnectionId: String

Here the RouteTableId is mandatory, and we want to connect it to our gateway so we use the GatewayId element.

Also the DestinationCidrBlock is mandatory (or the DestinationIpv6CidrBlock if you are defining IPv6 network). Here we would have the destination 0.0.0.0/0, AKA everything. So all traffic not going to the IP range of the VPC will be sent to that route.

Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
  RouteTableId: String
  SubnetId: String

Both are required.

So when we combine all this, we get:

---
Description: This is an attempt to create a VPC in a Cloudformation stack
Resources:
  VPC:
    Type: 'AWS::EC2::VPC'
    Properties:
      CidrBlock: 10.0.0.0/16

  SubNett:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.42.0/24
      VpcId: !Ref VPC

  InternetGW:
    Type: AWS::EC2::InternetGateway

  GatewayToInternet:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGW

  RouteTablePublic:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  RoutePublicIPv4:
    Type: AWS::EC2::Route
    Properties:
      DestinationCidrBlock: 0.0.0.0/0
      RouteTableId: !Ref RouteTablePublic
      GatewayId: !Ref InternetGW

  Route2Subnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTablePublic
      SubnetId: !Ref SubNett

And with that template, we have a functioning VPC with a subnet that can connect to the internet. In later blogs I will build upon this template to create a production ready VPC, and then build environments in those VPCs. Stay tuned.

Why Machine Learning models should run in Containers

Mon, 25 May 2020 00:00:00 +0000

Machine Learning (ML) is being implemented to varying extents in businesses all over. However, seamlessly integrating ML workflows into existing infrastructure can be somewhat challenging. This is the first article in a series on DevOps for Machine Learning - how to automate the ML process. In this chapter we will explore the benefits of running ML models as microservices and with what tools.

Why containers in the first place?

The initial demand for this solution came years ago. Software developers identified the need for better isolating installations and workloads on servers, without going for the more heavy-weight virtual machine strategy (vm).

For developers in particular, a smooth running of their application code outside of their laptop was not automatically a given. Different versions of software, other types of OS distributions and differing underlying infrastructure could easily create disturbance.

With the advent of Docker in 2013, containers became an increasingly popular solution to this problem. By running the application on a generic platform (PaaS), you can isolate the code and all of its dependencies in a container, where it can run effortlessly in any environment.

Upgrades and maintenance work done to the underlying infrastructure or OS, will therefore not compromise the code-dependecies of the application in the container.

Also, by moving application state to remote databases, containers can easily be discarded and spun up, enabling manageability and scale on a new level.

So how do you implement a ML model in a container?

A natural fit would be to wrap the model in a microservice. This is a REST based concept where the components of an application communicate over http instead of direct function calls.

This approach decouples the ML model from specific applications, giving the model a separate lifecycle while simultaneously offering the API endpoints to other applications.

There are several other benefits of running your ML model in this way. A container is more lightweight in comparison to a vm. It also transports well from training to testing and deployment. Having all dependencies wrapped up in a container there is no longer a problem with training your model from different environments.

Also, if several teammates are collaborating on the same model project, conflicts with existing versions of for example Python or Tensorflow will not affect the training itself. The container can be spun up anywhere, anytime, and will always be an exact duplicate of the original container image, whether it is right now, in a month or in years.

Furthermore, exposing your model container as an endpoint will separate it from its serving infrastructure, supporting decoupled architecture. This means that if you ever want to exchange the existing model for another, or implement it with other services, it is an easy switch and integration.

Last, but not least, containers need orchestration to be able to take full advantage of all the benefits. Orchestration manages traffic, meaning it can automatically provision, deploy and kill off containers according to the volume of queries from the application.

This presents several other convenient advantages for ML practitioners. One of them is for large training jobs. Orchestration can help you distribute the job over several nodes or containers, reducing the total amount of time to finish.

You can also train in parallel. Another benefit is the possibility of A/B testing for more robust models, this is well known to software developers. Here you can select subsets of the user-base to test the new model on, assessing directly whether your retrained model actually yields an improvement.

Furthermore you can roll out, test, deploy and roll back again as you like and whenever you want.

The tool box

On the tool side, Docker also offers Docker Hub, a free “store” offering an enormous set of ready-build images, both official ones from differing development communities and more informal ones from enthusiasts.

The quality does vary, but you can find container images offering eg. R or Tensorflow that will ease the initial setup. It should be noted that Docker is not the only player in this scene.RedHat has developed a drop-in replacement called Podman and also offers its own officially supported container image registry.

On the orchestration side, there is a plethora of solutions like Docker Swarm, Kubernetes and OKD/OpenShift (which utilises Kubernetes). Perhaps the easiest way to get started is by using a PaaS solution from a public cloud provider like AWS or Azure. They have a variety of options you can choose from.

With AWS, you could either do it from scratch, setting up a Docker container on a EC2 instance, or use the ready made ECS container service. In terms of orchestration you can run Kubernetes or Open Shift directly on the AWS platform, or you can use their EKS or ECS solutions where AWS offers prebuilt orchestration services.

Why not try and set your model up in a container the next time and see for yourself?

Contact

Mia Ryan
Sales Advisor at Redpill Linpro
Contact

Is your data green enough?

Fri, 17 Apr 2020 00:00:00 +0000

“Companies that opt to delay sustainable priorities over the next five years will find it impossible to catch up as sustainable business continues to become a new standard.”

Sustainability

(Instalment 1 of 3)

Green computing

The above quote is from Gartner who says this in the analysis “Build and advance sustainability programs”. Although primarily directed at the logistics business, the analysis is based on key factors that are just as important for the IT-sector and it’s data centers.

Data centers throughout the world are now using approximately 3 % of the worlds available energy (about the same as Great Britain), and are responsible for 2 % of the worlds total carbon dioxide emissions.
This is now more than the aviation industry, and these numbers are expected to double every 4 years.
This - obviously - cannot continue.

According to Gartner (and trends we see emerging more and more) - you should not be satisfied with this. Regardless of which part of this supply chain you are a part of, if you want to keep your business/customers, you have to change towards green.

Consumers

There is a big push towards sustainability in the consumer market. Forbes did a survey about this and concluded: “Our survey revealed an overwhelming demand for brands to step up on sustainable lifestyles. If your brand isn’t helping your consumers improve their environmental and social footprint, then you’re in danger of disappointing 88% of them.” This trend among consumers is coming to the IT-sector and it’s data centers as well. Should you, as a supplier in this market, follow your customers? Undoubtedly. But even better: Get there before them.

Suppliers

Some suppliers have already worked on this; Microsoft has a sustainability calculator that helps the customer see how much of what kind of energy goes into their server rig, either on-premises or in Azure. They also announced that they were 100% powered by renewable energy already in 2014, although by purchasing RECs (renewable energy credits).

Amazon (AWS) are building huge wind and solar farms to help them in their goal of achieving net zero carbon emissions by 2040.

Maybe the best idea so far is the dutch company Nerdalize who instead of putting their customers servers in data centers, put them in private households to heat radiators and water. (Unfortunately, they seem to have gone out of business since their crowdfunded startup in 2017).

There is a big challenge here: IT is rather dependent on electricity. Servers and data centers cannot just turn off the power at night to be environmentally and politically correct. There are however quite a few ways to be environmentally aware about this. Read the next instalment to learn more.

Contact

Yngve Sandal
Architect at Redpill Linpro
Contact

Why code your infrastructure?

Fri, 07 Feb 2020 00:00:00 +0000

One of the more popular buzz terms in infrastructure and cloud discussions these days is “Infrastructure as code”. But what is that exactly? How can infrastructure - previously supposed to consist of cabling, metal chassises and computer hardware - suddenly be lines of code? This article will assume that you are new to this field and will try to explain it from that point of view.

What it is

Very simply put, it is writing configuration files for how your infrastructure should look, and has been referred to as the Swiss army knife for both developers and systems administrators.

Code

Infrastructure

Wikipedia tells us that it “is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources.”

Although Infrastructure as Code (IaC) may be used to provision your data center, it is the advent of cloud computing that has really brought forth its value. Cloud computing, Infrastructure-as-a-Service (IaaS) and DevOps are all dependent on IaC, DevOps specifically because of the need for agile work processes and automated workflows.

So Infrastructure as code is just code.

Benefits

There has to be some, right?

Speed and simplicity. IaC lets you spin up an entire infrastructure of virtual servers, launch pre-configured databases, network infrastructure, load balancers, storage and whatever else it consists of, simply by running a script.
Configuration Consistency. Even with good documentations and standards, there will always be the chance of some deviation just from how that person executing the task chooses to do it. With IaC, the risk of this is severely reduced.
Minimization of risk. IaC not only automates the process, it also serves as a documentation of sorts - a description of how to create infrastructure. This will make the anxiety of that one engineer that knows everything quitting fade away to nothing. IaC - done correctly - is like a blueprint of your datacenter
Cost savings. Spend less time doing manual and repeating work and more on tasks that creates value for your company. IaC can also help you spin down again environments when they are no longer in use, saving money that way.

How to do it

There are a lot of tools available, both paid and free, open source and closed. Some may only be used with a specific provider, and some are provider-agnostic. We separate between configuration orchestration tools and configuration management tools.

Configuration orchestration tools are what you use to automate the deployment of servers and other infrastructure. Each of the three major public cloud providers each have their own tool, which can only be used there. AWS has CloudFormation, Google Cloud has Google Cloud Deployment Manager, and Microsoft Azure has Azure Resource Manager. In addition there is TerraForm from Hashicorp, which to some degree can be used on all the public cloud providers simultaneously and in addition integrate other third-party systems. The configuration languages used range from JSON and YAML to Python.

Configuration management tools are what you use for setting up and configuring systems, software and services on the before mentioned servers. There are a multitude of tools available for this, some of the most well-known are

Chef - where you create recipes and cookbooks in Ruby
Puppet - where you use Ruby to declare the state you want your systems to have and what they are supposed to do and Puppet will figure out how to get there (very simply put)
Saltstack - also a declarative tool using Python Some mentioned, a lot not mentioned, but not forgotten.

But it is - of course - not that clean and simple. There are some overlapping here between orchestration and management tools which you will find out once you start trying this out. Finding the tool(s) that best suit your needs is a major part of this undertaking.

(Some of the) Best Practices

Codify everything. Every part of your infrastructure and system specifications that are put into code is a part where you have solid documentation and where you don’t have to put in manual work when having to recreate it
Version Control. Source repository tools lik Git, Mercurial, Subversion, CodeCommit or similar should/must be used. This way you can keep your sanity when trying to track changes, you can also do rollbacks easily and make collaboration work.
Continuously test, integrate and deploy. IaC needs to be a part of your CI/CD plans, and is simultaneously a tool you can use to make your CI/CD work more smoothly.
Make the infrastructure code modular. In the same way that “decouple” is a mantra when designing your virtual infrastructure, you should also apply it to infrastructure code.
Aim for cattle, not pets. While not practical in a household, it will make life so much easier when designing infrastructure. Any infrastructure resource is to be viewed as cattle that can easily be replaced as opposed to a pet that should be kept alive at all costs (and possibly for emotional reasons?)

Who does it and should you do it? Everyone does it - at least they will tell you so. Remember the part about buzzword?
Should you do it? The answer is the same as to much of everything else in life - it depends. Chances are - if you are reading this, have understood most of it, and are starting to hum the IaC theme, you should. IaC will give you some, if not all of the benefits mentioned earlier both for large-scale deployments and for smaller more intimate server-environments for just the reasons listed earlier.

I was going to have a section at the end called “Why you shouldn’t do it”, but it didn’t seem to make much sense at this point.

Contact

Yngve Sandal
Architect at Redpill Linpro
Contact

Redpill Linpro

4 reasons why a container platform is the right way forward

1. Easy to get started with

2. Higher productivity

3. More time to innovate

4. Faster time to market

More to explore

Contact

Containers 101

The basics

Container architecture

Container orchestration

Container platforms: Platform as a Service (PaaS)

Further reading

Contact

Finalizing the VPC template

Why Outputs?

Real example

Adding Outputs

Adding export

Using the export in another template

Cleanup

Things to note about Exports

Uniqueness of the Name

Locking of resources

Nesting

Why nesting

The Parent stack.

Description and Parameters

Basic Resources

Subnets

Outputs

The child stacks

Description and Parameters

The Subnets

NAT Gateway and route table

Associating the subnets and route tables

Outputs

Take it for a spin…

Clean up afterwards.

Video conferencing and privacy, findings and conclusion

Findings - part 1

Findings - part 2

Jitsi Meet

Conclusions

Contact

Video conferencing and privacy, choosing a solution

The challenge

Choosing a solution

Methodology

Contact

Moving forward with Cloudformation templates

Humble beginnings

Public vs Private subnet

Public subnet

Private subnet

NAT Gateway

Private Subnet in Cloudformation

Dependency

How a subnet is defined

Route for a Private subnet

Private Subnet

Putting the parts together

More Availability Zones

Specifying the Availability Zone

Combining everything

VPC and Internet Gateway

Elastic IP addresses for the NAT Gateways

All the subnets…

The NAT Gateways

The Route Tables

The Routes

Association between route tables and subnets

Starting with Cloudformation templates

What is Cloudformation?

Resource for information

Anatomy of a template

Description

Metadata

Parameters