AWSome Dev Day 2019!
The AWS Dev Day is a free conference day hosted by Amazon where architects and developers from Amazon and other companies talk about the most popular AWS services, the newest features and everything related to cloud development. These sessions explain a lot about what AWS has to offer and you will see live demos on how you can implement them in your own use cases.
Amazon held their Belgian Dev Day in Mechelen this year. This was very convenient for us as the Ordina Belgium HQ is also located in Mechelen. This means that there was a very good reason for Ordina consultants to attend the event. We went with a small group of 8 people to make sure we didn’t miss the latest AWS news. We were treated with delicious food & drinks throughout the day to make sure their guests were happy.
CI/CD for Modern Applications by Sébastien Stormacq
In an application development environment, it is important to maintain your Infrastructure as Code (IaC) to allow for repeatability, and doing so in a declarative way. Doing it in an imperative way does not allow for deltas and requires your system to be rebuilt from scratch every time your pipeline gets triggered, which results in worse impact for your end users.
There are a number of ways to provide your infrastructure as a code declaratively. We have Terraform, CloudFormation, etc. But Amazon has a new kid on the block since this year: the Cloud Development Kit (CDK). This allows developers to provide your infrastructure in their favorite programming language. You can communicate with AWS in a way other than the AWS CLI or the Web Console, as you can now create services as you need them and when you need them.
All of this gives you the best toolkit to NOT create snowflake servers.
A snowflake server is a server that requires additional configuration in its environment that is often done manually. These are configuration steps that are done after the automatic pipeline process.
The CDK also has a CLI which can be installed by running
npm install -g aws-cdk.
Amazon’s pipeline service is called AWS CodePipeline. This service allows you to create a pipeline which executes all the necessary steps to automate your releases and to provide infrastructure updates. This allows you to quickly provide new releases and deliver new features to your end users. You can integrate this service with other external services (ex. GitHub, where your repository is hosted).
To effectively build your application, you can make use of AWS CodeBuild. This is their continuous integration service that packages your application by building it and running the tests. Pricing is very effective, as you will only pay by the minute when you trigger a build. CodeBuild automatically scales and can process multiple builds at the same time, so you won’t have to deal with build queues.
AWS CodeDeploy is a deployment service which basically allows you to deploy (almost) anywhere, including (but not limited to) on-premise servers. This service makes it easier to provide updates to your end users and to avoid downtime during the rollout of a new update.
One of the most impressive features is the Blue/Green deployment. This splits the traffic going to your application into traffic to your original environment and the new environment. The best use case for this would be during a new production release. You have a new release that you want to deploy? Simply let 10% of your traffic go to that release to make sure everything works right. After monitoring the release, you can choose to either revert or to fully allow traffic to go to the newest release.
Amazon provides a lot of tools that help you manage your builds and deploys, making sure that everything works according to plan. We are definitely fans of their new Cloud Development Kit and their Blue/Green deployment option is able to stabilize and fully control the rollout of a new deployment.
Integrate your front end apps with serverless backend in the cloud by Sébastien Stormacq
Serverless is a big trend nowadays and rightfully so as it takes away a lot of operational work from you! The biggest pros of serverless are that you no longer need to provision or manage your own servers, it automatically scales with usage, it has built in fault tolerance and fallback methods and last but not least, you only pay for the actual usage. This means that if you are not using your lambda, you are not paying for it!
Sebastian filled the session mostly with a demo in which he built a React app to communicate with his lambdas.
To provide his infrastructure (auth, GraphQL API etc.), he used the AWS Amplify CLI which is a new CLI tool that can add cloud features to your web or mobile application. For example, by simply typing
amplify add auth and
amplify push, you have created your own user authentication provider (Cognito). If you want to set up a GraphQL API (AWS AppSync), you just have to type
amplify add api followed by
amplify push. This creates an API and stores its data on a DynamoDB database.
To finally deploy his application, he simply used an S3 bucket that acts as a web server.
After all, React just builds static HTML / CSS / JS files which need a web server (Nginx, Apache) in order to be displayed.
Using an S3 bucket is very cost effective and doesn’t require anything else other than a bucket and correct bucket configuration.
So no Linux configuration, load balancer setup & costs, ….
amplify add hosting and
amplify publish, these steps are automatically done and it doesn’t require us to do anything else.
You can also enable production mode, which enables AWS CloudFront integration to send your website to edge locations, so you can provide faster loading times to your users from all over the world.
Amplify seems like a really handy CLI tool if you enjoy working with AWS. The commands are very similar to each other, and really simplifies deploying your application or integrating your application with AWS components. A new feature that has been introduced to Amplify is Predictions, which provides a solution for Artificial Intelligence & Machine Learning cloud services to let your application make use of. Overall, the future for Amplify is very bright and I can see it growing more as more developers adopt it in their current workflow. After all, who doesn’t like to just type one command and everything is taken care of?
Breaking the Monolith: road to containerizing your app by Juan Lage
A monolith is basically one big application that handles everything that your project needs to do. From security to having all your services in one package. This is simple, has no over-engineering (on the architecture part), faster communication as everything happens in-memory and you have one code base. BUT, monoliths grow old as well, and the older it gets, the more code it has. They scale pretty poorly and are tightly coupled systems. Your developers are also required to learn more business logic and your deployments are all or nothing, meaning that, if your application goes down, your whole infrastructure is down, which isn’t interesting for an application where a lot of people depend on it.
Dividing your monolith into a microservice architecture improves your workflow by splitting up your team to work on each microservice. This also helps your architecture in a way that each microservice has their own single responsibility. However, splitting a monolith is not a simple task and requires a lot of work to make sure you split it up the right way.
Once you have your microservices, the goal is to containerize each service.
Fargate is a service that helps you with this. It’s basically a serverless implementation for containers, meaning that it manages servers and clusters for you. Simply provision your container and Fargate does the rest for you by using Amazon ECS to provision your container on the cloud. It’s a really useful tool if you don’t want to manage your own server or cluster.
Code base, config, dependencies, …
The rest of the session was a very interesting take on how you actually can split up your monolith into microservices. It’s useful to have multiple code bases per service with their own deploy pipeline to deploy to your environments.
It’s also a good practice to isolate your application from your dependencies. You should also explicitly say which dependencies you want and which version that you want. This helps you to build and create immutable images with explicitly defined dependencies, so you can run the same image in multiple environments.
Your configuration is also very important in this. Configuration (database credentials, authentication keys, …) changes with each environment. If you hardcode those values, you will never be able to create an immutable image. It is important to externalize your configuration by storing it in your environment or by using an external service that stores your configuration. AWS Secrets Manager is a service where you can store sensitive configuration that your application can pull up when needed.
He gave a lot more hints and associated AWS components that can help you achieve your goals in splitting up your monolith. Make sure that you take your time with this, as this is a very important factor in your project that needs to be done right. When done right, you will see an exponential rise in productivity and the addition of features and thus, making your end users happy with your service. AWS has a lot of services that can help you and you should take your time to get familiar with them.
We ended the day with a Gouden Carolus, which is the most famous beer that is brewed in Mechelen. Overall, it was a very nice experience which I would love to attend again in the future. You get familiar with a lot of AWS components that you didn’t know before and they showcase a lot of services.