Not rendering correctly? View this email as a web page here.
dev-bf-june-2020-header

Morning fellow developers!

Summer is finally here. Whether you have already started your holiday or waiting for the season to kick in, it's time to take a breather and enjoy the beautiful weather. In this month's Dev Breakfast, we'll learn from Antti and his client work.

 

Antti_Futurice

 

I’m Antti, a developer and tech lead working with the energy industry at Futurice Tammerforce. My team is currently working on implementing AWS cloud architecture for a multi-product extranet application (think multiple running instances from the same codebase) that used to run in an on-premise environment. In this endeavour we need to manage nine different product-environment-combos, each running on their own AWS account, so it’s crucial that we can automate (CI/CD) and unify (infrastructure as code) as many things as possible, as well as utilize existing solutions where possible. Here are some things that we have had in active use lately, that have proven helpful.

Antti's Picks

AWS CDK

 

AWS CDK

There are a few alternatives for writing AWS cloud infrastructure as code, most notably Cloudformation (AWS’s own solution), Terraform, Pulumi, and AWS CDK. Since we didn’t need to be cloud provider agnostic – an advantage Terraform and Pulumi have – we opted for AWS CDK, or “Cloud Development Kit”. What it offers is basically a programmatic way to define the cloud infrastructure as code instead of some sort of configuration markup language, so TypeScript in our case. Since all the application code is TypeScript anyway, this reduces the overhead of switching between languages for different tasks.

The CDK is basically just an abstraction layer on top of Cloudformation – you write code that outputs and deploys Cloudformation templates – so Cloudformation’s caveats apply here as well. What’s nice though is that CDK abstracts away all the complex references between resources. And most importantly, we don’t need to define any IAM policies ourselves, but CDK does all that automagically. Also, since the code is just TypeScript, we can reference “process.env” just like in application code, and configure the infrastructure dynamically for all the different products and environments without repeating code. We can just “cdk deploy” with different environment variables to apply the changes to any of the nine AWS environments we work on.

We use the CDK code, a single repository, to define pretty much everything related to any given environment-product-combo, i.e. a single AWS account. The CDK code creates a VPC with the needed subnets, different ECS clusters for microservices and frontend services that run on Fargate, all the load balancers, their rules and security groups, an RDS instance and the links between that and the microservices using it, a Cognito user pool and app client, a DynamoDB table for user metadata, an API Gateway for the backend services, and so on. CDK takes care of gluing everything together nicely, without i.e. having to manually set permissions or target IPs between services. We also don’t need to manually create Internet Gateways, Elastic Network Interfaces, Route Tables or NAT Gateways to make everything work, CDK handles that behind the scenes.

AWS CDK is not very mature tech by any means, and there’s a new minor release pretty much every week, but we still haven’t run into a thing we couldn’t have pulled off using it. Nor have we regretted the decision to choose it over, say, Terraform. I recommend trying it out if you work with the AWS cloud!

Read more on AWS CDK
Github Actions

 

Github Actions

GitHub launched Actions a while back, and we fell in love with it on the first try. We used to run our CI tests on Travis before, with the “1 concurrent job” plan, and with multi-product test matrices, one CI job took up to 15 minutes to complete. I have no major complaints about using Travis, but implementing the CI in GitHub Actions just felt so pleasant from the start. GitHub has a very nice built-in UI editor for the Actions workflows, so the feedback cycle of tweaking and running the CI configuration felt very short and effective. On top of that, GitHub Actions offers the same functionality that Travis offers plus multiple concurrent jobs instead of one, so we got our CI run duration from 15ish minutes down to 3ish minutes, and all this for free up to a generous amount of monthly computation minutes for private repos (unlimited minutes for public ones).

And to make things even more awesome, there are lots of readily provided actions – independent tasks you can use to compose a workflow such as running CI tests – available. In our case the most helpful ones are the ones from AWS, that take care of e.g. logging into AWS, pushing images to ECR, and such. So we were able to build a CI/CD pipeline that builds and tags a Docker image, pushes it to the related ECR repository, and updates the running ECS service’s task definition with the updated image. All with minimal manual implementation needed.

I really encourage everyone to take a look at GitHub Actions, it’s awesome!

Read more on Github actions

AWS Amplify-js

 

AWS Amplify-js (the JavaScript library)

AWS Amplify is ”a development platform for building secure, scalable mobile and web applications” with features ranging from analytics to authentication. It features a CLI for creating whole application infrastructures in AWS, automating the creation of e.g. API Gateways, Lambda backend functions, DynamoDB storage, Cognito authentication and authorization, and Cloudfront hosting for the frontend, as well as the interconnecting IAM roles, making the initial creation and deployment of such applications very seamless.

But wait, how does that apply to our case when we are already using the CDK for defining and deploying the infrastructure?

What’s not obvious from AWS’s way of advertising Amplify (“use this to do everything!”) is that a part of Amplify is also the amplify-js JavaScript library, that contains all the useful bindings for the commonly used AWS services. It’s like aws-sdk but with a declarative API and better development experience. In our case, the most notable service integration is Cognito, and the Amplify library even provides a full blown React UI component library for integrating the whole sign-up and sign-in process very swiftly.

To be honest, amplify-js is far from mature in certain areas, but it’s open source and the maintainers are open to pull requests. Using the library we were able to build the whole sign-up and sign-in functionality in a matter of days, and focus on the actual business logic.

Read more on amplify js

 

I'm a developer, not a coder

 

Blog Post: I’m a Developer, not a Coder

Coming from a business education background, my entry to the software development industry isn’t necessarily the most typical one. I’ve always viewed myself more as a developer of concepts and implementations than a coder. I wrote about how this shows in my work in the Futurice blog lately.

Read more

 

CDN Under the hood

Content Delivery Networks: Under the hood

by Jyrki Pulliainen

Maybe you are familiar with using Content Delivery Networks, or CDNs for short? Maybe you have even used them yourself? Or maybe this is all news to you?

Let’s have a talk where we look into CDNs under the hood. What are they, who are they, why should you use one (or maybe should not), and how do they work? The CDN landscape is also changing, so we’ll dive into that a bit.

And we’ll go through why you shouldn’t build one yourself.


Watch now: Latest on Techweeklies

 

Jobs

Lead Developer | Tampere

Do you really love your life in Tampere, but wouldn’t mind adding a bit more international flavor to your everyday work? Now you have a chance to do this from our office in the heart of Tampere!

We are looking for lead developers who thrive in a flexible environment that encourages continuous learning.

Read more

 

Senior Data Engineer | Tampere

Do you enjoy developing data-driven applications and intelligent solutions in co-operation with other team members and clients? Now you have a chance to do this from our office in the heart of Tampere!

We are looking for an experienced data engineer who thrives in a flexible environment that encourages continuous learning.

Read more

 

Futurice - Work with us!