Author: Lockhead

A second look at Amazon CodeCatalyst – CI/CD natively on AWS to empower developers to deliver faster and reduce heavy lifting for small to medium software engineering and DevOps teams

A few weeks ago, on december 1st 2022, Werner Vogels announced Amazon CodeCatalyst. I’ve previously shared my initial thoughts and findings in a blog post. In this post, I’m going to share a few more findings and insights into using Amazon CodeCatalyst and will also see if any of my wishes from the wishlist for CI/CD on AWS have been resolved with CodeCatalyst.

What I have been playing around with…

CodeCatalyst login page

One of my personal projects that I am working on together with a few friends is pegasus-galaxy.net and the CI/CD pipeline that I had built with CDK Pipelines (that I also presented at re:Invent 2022) was the first one to try to move over.
In context, we’re talking about a Flutter application for Web running behind CloudFront, deployed using CDK.

I decided to try CodeCatalyst out and go “all in” – and that means moving the code from Bitbucket into CodeCatalyst as well as setting up the other users in CodeCatalyst and moving the workflows (=CI/CD pipelines) over to CodeCatalyst.

CodeCatalyst Menu

In this article I am going to go through each of the sections in CodeCatalyst and will share my experiences, thoughts and findings.

Where I have ideas on how to improve the day-to-day work with the tool, will try to share that.

Before going into details, lets start with the most important thing:

Amazon CodeCatalyst works very well and reliable and the current version of the service is a great foundation for moving all of your CI/CD and development practices to AWS.

The CodeCatalyst team has been very supportive on re:Post, so if you have a question, feel free to ask it there!

CodeCatalyst Overview – Spaces and Projects

Spaces are the “Top-Level” option to organize your CodeCatalyst account. You will need to associate an AWS Account for billing used AWS resources. Each AWS (billing) account can be associated only with one CodeCatalyst Space.

CodeCatalyst Spaces Billing page

While this seems like a limitation as you will need to create a different billing account for a 2nd space, I can right now not see an impact for my day to day work. For anything that I run on the same AWS account, I would assume that using a project within the same space should be good.

You can manage Projects, Members and AWS Account connections on the space page. In the “extensions”, CodeCatalyst currently allows a connection only to the JIRA Cloud. I would expect that additional 3rd party extensions will be supported in the GA version of CodeCatalyst.

Projects Overview and options

A project is a “unit of work” in your product or software that you are building.
Within projects, you can manage issues, manage your code repositories, execute workflows (CI/CD) and review report results.

Projects are associated to a Space – and you can create as much projects in a Space as you want. You can add team members to a project, that are not able to access all projects in the space. Unfortunately I have not yet found an option to “hide” projects from Team members that are added on the Space itself.

Managing issues / tickets

CodeCatalyst currently provides two options to manage your issues or tasks:
1) Link to JIRA Cloud Project
2) Internal issue management

If you use the option to link to a JIRA cloud project, the “issues” link is replaced by a link to your JIRA Cloud project.

Internal issue management

The internal issue management system currently offers everything that is required for a simple Kanban workflow. You can create issues, add them to a backlog or a Kanban board, assign them to project members and track their current status.
I personally think that the current functionalities are good enough for small teams and simple projects – I’m actually already working with it in a small project and will add additional feedback as soon as I gain more experience.

Code

Within the “Source” part of a project, you can manage source repositories or connections to source repositories in Github. I expect that other providers will be added going forward (e.g. Gitlab, CodeCommit, Bitbucket, …).
You can also manage pull requests and approvals – I was only able to test this using internal source repositories, not using a linked repository.

The last option – the Dev Environments – is the most exciting functionality – it gives you the possibility to host development environments (similar to Gitpod) on AWS using Cloud9 but also, and this is really cool, using Visual Studio or JetBrains IDEs.
When using that option, the IDE on your local PC is only the “presentation layer”, the source code is stored and run on an AWS instance and the IDE uses remote connectivity to talk to the Dev Environment in the background.

CI/CD

CodeCatalyst currently uses the same approach as Github Actions to manage your workflows or CI/CD pipelines – you are able to manage your Workflows using YAML files. The syntax is simple and understandable. There is a minimal set of Actions available as part of the preview. You are also able to use existing Github Actions as part of your workflow.

Workflow overview in CodeCatalyst

The workflow functionality is very powerful. In my tests I have not yet been able to test all parts of the capabilities. Workflows can be defined for certain directories, for certain triggers or branches. Test reports will be exposed in the “reports” functionality.

CodeCatalyst offers a graphical overview for workflows and alows to edit them in the UI, too. This functionaly works pretty well and helps to quickly get you started building your first workflow in CodeCatalyst.

I’ll need to test the workflows more to be able to give additional insights into how good or bad they are currently running. My simple pipeline that builds a Flutter Application, deploys my Infrastructure as Code using CDK and then publishes the new version of the Flutter app runs without problems.

One of my main concerns so far is the execution time, however the team has been working on a possibility to use Lambda as an execution environment.
This option however does not yet support the execution of Github actions and also has some other limitations.

The other features that are part of the “CI/CD” – Environments, Compute and Secrets – I did not have time to play around with this. If you have any experiences with it, please add your thoughts in a comment to this article!

Reports

The reports today only suport test reports. I have not used the functionality enough to assess this, but I am sure that the CodeCatalyst team is going to add additional reporting options going forward.

Things I like most about CodeCatalyst (Preview) after 6 weeks of usage

Just a short list of things that I already like:
– Integration of Github Actions as workflow actions
– Managing workflows using UI & code

Things I miss in CodeCatalyst (Preview) after 6 weeks of usage

– macOS builds (e.g. for Flutter iOS apps) are still not possible
– granular permissions for workflow and Pull Request triggers
– and….

Let’s talk about Open Source Projects

Right now there is no option to share a project or a repository that is hosted within CodeCatalyst as an Open Source project. This is really a limitation if you want to use CodeCatalyst for Open Source project – or if I would like to share a CodeCatalyst repository with example workflows.
I hope this functionality will be added soon.

Wrap up and next steps for me with CodeCatalyst

I need to admit – writing this post took longer than expected 🙂
I wanted to publish it before christmas and now it seems to be a bit “late” already as I am sure that a lot of you have made your own experiences with CodeCatalyst today – please SHARE your findings with me – links of Blogs that you have written or other content you have created, I am eager to consume it!

My next steps with CodeCatalyst

I am working on migrating my project pegasus-galaxy.net completely to CodeCatalyst and collaborate with my team on it there. With that, I will be able to proof CodeCatalyst in a “real world” application that it is “multi-platform” application – using Flutter for Web, Android and iOS – and a Serverless AWS based backend.
If you’re interested to join this project, please do not hesitate to reach out – skills that we need right now:
AppSync, DynamoDB and development/software engineering (Flutter, Typescript, Java, or Node?)

Views: 354

A few personal stories from re:Invent 2022

As we are now in the post:Invent phase of 2022 and over 10 days have passed since re:Invent 2022 in Las Vegas was concluded, it’s time for a lot of re:Cap Blog posts and events.
I’ve read so many of those “major announcments” articles that I’ve decided to write a different type of re:Cap for myself this year:
Sharing a few stories from my 10+ days in Las Vegas, as they are as equally important as the technical announcements made by AWS.

Indeed, it was a great conference with a lot of learnings and a lot of very interesting sessions. I focused on Chalk Talks, Builder’s sessions and events (like Gameday) as these are not recorded.

Making new friends before re:Invent kicks off

My flight this year got moved from Saturday to Friday, so I had one more day to get over Jet-Lag. On Friday, I spend a good time shopping and besides that met with Oliver vor dinner. On saturday morning (early morning!), I looked at the AWS Community Builders Slack and found out that Traian set up a “spontanous breakfast” for the Jet-lagged folks – and I ended up sitting over two hours with different parties, having fun, chatting and getting to know people. It was exciting to meet Rafael, who had been our Solutions Architect for a while, for the first time in person – without planning it 🙂
It was also great to meet Heitor in person – the person that owns the Lambda Power Tools at AWS. His talk is now on Youtube and I would encourage you to listen to it if you are interested in Open Source.

The rest of the saturday I spend with Markus, who shared so much Las Vegas knowledge with me that I think my brain is still burning – and I would not dare to claim remembering more than half of what we discussed – but it was a great saturday which ended with meeting Philipp for dinner at “The Cheasecake factory”.

I kicked off the sunday with a lot of excitement about my very first talk at re:Invent – final technical check in the “Speaker Ready Room” for my slide deck! That needed to be early morning, because afterwards I had planned to go out hiking with fellow AWS Community Builders.

Hiking across time zones and cultures

Definately one of my highlights this year: The ever first AWS Community Builders pre:Invent Hiking Trip!

Thanks to everyone that joined – Oliver, Richard, Jenn, Ganesh, Traian, Pubudu, Niklas. It was great to see how we supported each other, had great conversations and all managed to get across different challenges we had to fight!


Thank you Oliver (and kreuzwerker) for the amazing video.
Traian, you’re my hero. Congratulations on finishing off the hike with us with. Thats an achievement noone can take away.

It was fascinating to meet you all for the first time and notice that we get a long well, without ever meeting before. That’s the power of the AWS community!

We got back at 6pm, after a over 5 hours hike, just in time to get our AWS re:Invent badges and to meet other AWS Community Builders from around the globe for a great dinner. Lilly & Jason – thanks for joining us, that really made me happy!

Welcome to re:Invent

Kicking off re:Invent with a GameDay with a great team an Jeff Barr

I decided to kick off my re:Invent on Monday with a GameDay – which is a fascinating opportunity for gamified learning. On sunday, during our hike, I had aligned with Niklas to form a team together – and the other two team members, JaeJun and Martin, we met in the morning. We had great fun, ended up 4th even tho Jeff Barr distracted us for some time as we won him on our table with a quizz. It was great meeting him in person – and I can tell you: He is a human as we are, even if his Newsblog is legendary 🙂

Meeting people from the AWS Community

I had so much great hours in Las Vegas – thanks for the time spend together, everyone that I’ve met – Stefanie, Oliver, Manuel, Mike, Stefan, Philipp, Markus, Thorsten – and others – from the german community.


Finally met Danielle and Matt in person. Another of my highlights.



The Community Builders Mixer and the User Group Leader Mixer where both great events to get to know each other better and network with great people from everywhere in the world. I met so many people that I had been interacting with in written (Slack, Twitter, LinkedIn) – it was a blast for myself.

Famous Jenga-game with AWS Heros – so much fun!

Famous Jenga-game with AWS Heros – so much fun!

Speaking at re:Invent 2022 – my DevChat

As I’ve already shared before this year I had the opportunity to speak at re:Invent – COM307 – Using CDK pipelines (in Java) to build a multi-platform Flutter application

Thanks for everyone that made this possible: Ernesto, Shantavia, Lilly, Jason, Maria! It was my biggest honor to share my experiences and my open source initiative. Looking forward to keep sharing knowledge!

Announcing Amazon CodeCatalyst

With the announcement of Amazon CodeCatalyst the conference brought for me a new service that I am eager to use and try out as I am very much interested in CI/CD on AWS.
This was for me definately the most exciting anouncement of re:Invent 2022 and I had a lot of interest to talk to the service team, product managers and others after the service had been announced. I’m looking forward to share more about that as I get to play around with it more.

Flying out

On saturday my trip to re:Invent was over and it ended as my re:Invent trip began: meeting AWS interested persons at the airport (Thanks Maria for the introduction!) and with great conversations with Oliver on the way back to Frankfurt.


Thanks to everyone that I met and talked to at re:Invent 2022 – you really made this conference be a different one for me than it was before.

I’m looking forward to hopefully meet all of you again in 2023!

Views: 374

A first look at Amazon CodeCatalyst – Managing your Cloud-Build & Deployment infrastructure natively on AWS

In this post you are going to get to know the new service that AWS announced at re:Invent 2022 in Las Vegas. With this new service AWS brings the Code* tools (CodeStar, CodeBuild, CodePipelines, etc.) into one user interface and opens up the usage to new audiences.

Amazon CodeCatalyst is a service that helps you to manage your project code in a central place and allows integrating it with existing CI/CD tools. It also simplifies the cross account functionalities of CI/CD best practices. With the market place functionality it opens up the tool for further expansion through third party contributors.

Functionality highlights

Organizations and projects

CodeCatalyst allows the set up of an organization and projects within that organization. This allows a structured set up of your projects and allows you to segregate access. What I have not been able to verify is if existing organizations of AWS Organizations are automatically imported and available in the service. This would be beneficial for larger organizations that want to get started with CI/CD on AWS.

Integration with your “builder ID”

Amazon CodeCatalyst is integrated with AWS your builder id – and that means that you can have a unique, personal account. This account is not tied or attached to an existing AWS account. The integration with the AWS accounts it done through cross account permissions that are created automatically for you. This concept has various benefits:

  • You (as a developer) can have access to the required CI/CD structure and code management without the requirement to have an IAM user or access to the AWS console to the specific AWS account that you are aiming to deploy to
  • You (as a developer) can have access to different “organizations” and “projects” within the service – which will make it easier for 3rd party teams working on AWS projects (e.g. consultancy engagements)
  • You can allow the CodeCatalyst workflows to only be able to deploy into certain accounts and the list of accounts that you can connect to from a specific project or organization can be modified on demand

Unified user interface and workflows

The new user interface of CodeCatalyst allows to look at the complete lifecycle of your product – form development to deployment – within the same window. You can easily set up a project, connect or set up a repository and then create a CI/CD pipeline (or workflow) for it. You will also be able to visualize the workflow of your CI/CD pipeline during creation or editing.

Integration of Github Actions

With the integration of existing Github actions and the possibility to re-use already available automation steps within your workflow AWS opens the door to re-use and migrate a lot of already existing functionality. This is going to be very beneficial and will help to drive the adoption of the service. The availability of “native” actions as part of CodeCatalyst is still limited and I assume with the Marketplace new actions will be made available quickly and the list of available actions will grow rapidly.

Project Templates – CI/CD pipelines

I believe that this is the most important functionality of the service. Allowing to quickly set up new applications, workflows or projects on the service empowers developers to get started efficiently. I’m eager to see additional templates going forward. As you can include both infrastructure and application code, but also the required workflow in a template (=that’s your deployment pipeline), I hope that with this functionality we will be able to empower developers to re-use better CI/CD pipelines that enforce a DevSecOps mindset and include all of the “best practices”. I would love to see all of the reference implementations of the “DPRA” (Deployment Pipeline Reference Implementation) implemented as templates in this service.

A good, automated CI/CD pipeline helps your developers to focus on creating business value – the more you can “re-use” or drive through standards and templates, there more efficient your teams will be.

Additional wishes

As I have not explored all areas of CodeCatalyst yet, some of my “wishes” might already be implemented and I did not yet discover them – here’s a few things that I’d love to see but haven’t found yet. Please reach out to me if this is functionality that is available somewhere and I’ve missed to find it 😊

Re-applying project templates

I would love to be able to re-apply a project template to an existing project, especially for the workflows. This allows two things: 1) if you’ve changed the workflow and it doesn’t work anymore, you can quickly go back to the working version.  2) if the template changes, you can re-apply the changes to a project without the need to access every project manually.

In combination, some times a project changes or evolves and you might want to move it from a “backend” project-template to a “full-stack” project. This can today only be achieve manually but not in an automated fashion.

Better “mobile app” support

As you’ve maybe read, I’m working on a “Flutter” application – and because of that I would really love to see a possibility in CodeCatalyst that better supports the “cross platform” app functionality. Today, the service mainly focuses on provisioning AWS infrastructure. As you build a complex project that also needs to publish a mobile application, it would be very bene be able to use the service to also publish the application itself into the different stores automatically. Of course there are other, 3rd party systems that already allow that, but if you want to use CI/CD natively on AWS this is currently not possible. I know I’ve mentioned that before, but as I have not seen the possibility to perform an iOS build on CodeCatalyst, I wanted to highlight it again.

Additional 3rd party integrations / workflows

One of the assets of the service is definitely the market place functionality that will quickly allow to integrate new 3rd party services. What I would like to see here is the support of additional repository stores besides Github (e.g. Bitbucket, Gitlab, and the corresponding “datacenter” versions), but also the possibility of a native integration of other tools that are required as part of the CI/CD pipeline – things like Codecov, SonarQube, Checkmarx, Snyk, Aquasec, etc. This might be possible through custom actions, but I am not yet clear on how fast these will be available.

Infrastructure as Code support for provisioning and setting up your CodeCatalyst environment

I’m not clear about the possibility to set up your CodeCatalyst environment through Cloudformation/CLI calls or through CDK/Terraform and I am unsure if that would be something that is required for this service. What would definitely be good to have is the possibility to set up integrations to your existing accounts and projects in an automated form – the CLI commands make that possible, but that’s not the same as directly defining it “as code”.

Native branch support for projects & workflows

CodeCatalyst allows to refer to different branches, but it would be cool to get a possibility to natively support “ephemeral” environments as part of your CI/CD process. There are two use cases that I have in mind:

  1. Integration tests as part of the CI/CD process (workflow) that require the infrastructure to be available and provisioned
  2. Environments to replicate/test defects or new functionality

For both of these use cases, the CI/CD tool should be able to deploy an environment from a branch – and then also automatically de-provision it based on rules. Today this is something that you would need to manually replicate within your workflows and infrastructure as code.

Overall summary and outlook

The service is overall is a great addition (or maybe a replacement?) of the existing Code* tools on AWS and it streamlines a lot of things that were previously not working perfectly on AWS. For a new service it’s a solid launch with a lot of benefits, especially for small companies or open source projects that do not have the possibility to use existing third party tools or really just want to focus on generating business value. I do not think that CodeCatalyst will be able to replace existing Jenkins installations or services for bigger enterprises right now, as there are a few things that are not yet possible.

What do you think of CodeCatalyst?  Please share your thoughts and feedback with me (either on the comments, on LinkedIn or by mail.

Views: 880

How to save costs using AWS Lambda SnapStart for Java based functions

At re:Invent 2022 in Las Vegas AWS has announced a new feature for AWS Lambda that allows you to reduce your lambda startup times for Java based functions – SnapStart. With this post you are going to understand how the feature works, how it can be enabled, how you will benefit from it and how it will reduce your costs for AWS lambda. The functionality needs to be activated (“opt-in”) and has a few pre-requites for your functions that I will also share with you. It is currently only available if you use Java (Corretto 11) as a runtime. Other runtimes (e.g. Python, Typescript) will be available at a later date.

What is AWS Lambda SnapStart – and reduced latency for cold starts?

SnapStart is a new feature that helps to improve the “cold starts” of your lambda function.

AWS Lambda is a serverless possibility to execute code or a part of your application on AWS. The service can be used with different languages – Typescript/Node.JS, Python, Golang, … and Java. Lambda can be seen as “function as a service” with very convenient integration possibilities. Under the hood of Lambda, AWS has a very quick and mature provisioning system that brings up a container that executes your code. AWS Lambda as a “serverless” service allows you to not pay anything for your deployed infrastructure if it is not being used – this is also known as “scale-to-zero”. AWS Lambda is billed by “usage time” of the capacity that your lambda functions use – a lambda function can run up to 15min, but most of the lambda functions execute within a few seconds. Because of the  “scale-to-zero” functionality, there is not always a “running” version of your code on AWS. This is where AWS distinguishes between “cold starts” and “warm starts” for your lambda function.

When SnapStart is enabled, function code is initialized once when a function version is published. Lambda then takes a snapshot of the memory and disk state of the initialized execution environment, persists the encrypted snapshot, and caches it for low-latency access. When the function is first invoked or subsequently scaled, Lambda resumes new execution environments from the persisted snapshot instead of initializing from scratch, avoiding several seconds of variable latency.

So – why is SnapStart an “opt-in” feature?

AWS has decided to not make SnapStart a default functionality of AWS Lambda, because there are certain pre-requisites for being able to use this new functionality.

The most important one is that the code executed as part of the lambda function cannot rely on the “randomization” features of Java, and this has implications for the code that you write. Please read the SnapChart documentation for further details – the FAQ is very detailed on  this. This does not only include the code that YOU write as part of your lambda function but also the code of every library that you use as part of your code.

Other things to consider are that you cannot rely on network connections that you created/set up during the initialization of your code to be still valid and available when your function is resumed from a snapshort. This means that you will need to verify any network connections (e.g. connections for a backend database) before you actually use it.

Any ephemeral data that you rely on can be invalid when your function is resumed from a snapshot – and this means that you will need to ensure that any ephemeral data is still valid if you want to access it. This could be temporary credentials, machine learning models or just temporary data that you use within your function.

In it’s documentation, AWS also provides a bunch of examples and best practices to make sure that your code is “SnapSafe” and can work with this new functionality without causing problems.

How do you activate AWS Lambda SnapStart?

You can activate AWS Lambda either in the AWS console or through the AWS cli. Surprisingly this feature also comes with direct CloudFormation, CDK and SDK support. Please remember that after activating it, you will need to create a new version of lambda function that you want to test.

Further details can be found in the AWS documentation.

Let’s go back to the “teaser” of this post – How can YOU safe costs with this functionality?

For Lambda functions you are based on the number of requests for your functions, the allocated memory and the time that it takes to execute your java code. The duration is calculated from the time your code begins executing until it returns or otherwise terminated, rounded up to the nearest 1ms.

The total duration is a combination of the initialization code (in the constructor of your function) and the code in the “handler”.
With SnapStart enabled, the “initialization code” / phase is moved to the provisioning of the function (when you set it up) – and when the function is executed the “initialization phase” is replaced by re-starting the function from the already created snapshot.

This means that for functions, that have an intense “initialization” phase the potential savings are bigger than for functions that run all of their code in the “handler”. More details around how to optimize your Java functions for cold starts can be found in this blog.

Let’s do a few calculations on how this helps us to safe money:

The table assumes that the initialization phase is reduced to 25 milliseconds (which is not technically correct according to the AWS documentation, but its as close as I can guess today).

What this table shows is that the SnapStart feature will help us to reduce our costs for AWS Lambda significantly, if we have Lambda functions that have a longer initialization time than “handler”  execution time.

Overall I calculated between 10% and 60% savings with this feature, depending on your use case. Please be aware: This is calculation/guessing only, I have not yet measured that during a test! For further analysis and details you will need to analyze your current performance metrics of your lambda functions and perform additional tests and calculations.
Before you can use the feature, as already mentioned, you will need to verify that your lambda code is “SnapSafe”.

If you try out this new feature and gain meaningful experiences out of it, please let me know and reach out to me in the comments section, through LinkedIn or E-Mail.

Views: 862

How the AWS Community Builders program made re:Invent 2022 feel like “coming home” even tho I went there on my own

re:Invent 2022 is about to start in Las Vegas and I am really looking forward to all of the sessions, the gamified learning possibilities and all of the other things that make the conference great. But more than that, AWS re:Invent this year feels for me like “coming home” instead of “going to a conference”.

Let me explain you why:

In march 2022 I received my acceptance to the AWS Community Builders program.

 After that a lot of things changed for me and I would like to share some of them with you!

I got added to the Community Builders program and with that I gained access to great networking opportunities, sessions, talks and events and also some information that are not publicly available. Next, I introduced myself to a bunch of folks and people and quickly interacted and connected with other Builders around the globe. I saw the Call for Papers (CfP) for CDK day and we had a great panel discussion with a few builders – Danielle, Saima, Christian and Matt – about “The local cloud” at CDK Day 2022. Afterwards I attended the AWS Summit in Berlin and got to know a lot of great people of the AWS Community DACH in person (just to mention a few: Linda, Markus, Thorsten,  Aaron, Stefan, Nora, Henning…). This summit made me understand how important community work is for me and how much I gain from talking and networking – re:Meet, as Christian recently said.

I kept enjoying conversations with a lot of builders, getting to know a lot of them better. Later in the year, I kicked off the “AWS UserGroup Bergstraße” and we started having regular meetups. I also joined the “AWS Community Day DACH” organizational group and helped to found the “AWS Community Support Organization” for the AWS DACH community…and was able to give a presentation at the AWS Community Day 2022 in Dresden. I met more great members of the AWS community, got to know them in person and spend time with them.

As part of the Community Builders program there also was a CfP for talks & sessions at re:Invent 2022 – I submitted four talks and as I already mentioned I was fortunate and one of them has been selected as a DevChat for this year’s re:Invent.

At that time I decided that I would be attending re:Invent in person, to get the chance to give the talk and share my experiences. I did not know that no one from my company or close friends would be joining me in Las Vegas. I was expecting to take along a few of my close friends and colleagues. Instead, I’m on my way to re:Invent alone.

And still, I’m coming home and I have  the feeling its going to be the best re:Invent I have ever attended.

I’ll be meeting a lot of Community Builders I have never seen before – even on the flight today there were a few people I knew “from the community” and from my other investments into AWS (Tobias, Oliver, Henning, …). On Sunday, we’re going to be doing the ever-first pre:Invent Community Builders Hiking event with more than 10 builders I’ve never met before. Afterwards, we will be meeting up with more than 20 builders for a self-organized dinner event.

And then, on Monday, the conference will start where, I will feel like being part of the “big AWS builders family” that Werner was talking about at his keynote a few years ago.

The whole week is filled with meetings, 1on1, sessions – and dinners, parties,…

These things make me feel at home in Las Vegas!

Looking forward to meet all of you in person and talk, learn and have fun. Reach out if you want to meet me “live”. 😊

I can’t be more thankful to be part of this great community.

Views: 376

Continuous Integration and Deployment on AWS – and my wishlist for CI/CD Tools on AWS

As I’ve been sharing before, I am very fortunate this year and will be giving a DevChat at the biggest AWS conference of the world – at re:Invent 2022 in Las Vegas.

AWS offers different tools for all parts of your CI/CD lifecyle.
In this post I am going to cover the set of Code* tools that are available on AWS today – and will share my thoughts about what these tools are missing.

As part of the preparation for the talk and as part of both my private project (code-name: MPAGA) and my main job @ FICO I have been researching and learning a lot about CI/CD (Continuous Integration and Continuous Deployment) – and for the private projects especially around CI/CD that natively runs on AWS.
I’ve found out that not everything that these tools offer today is perfect and wanted to share some ideas on what could be improved. Where possible or applicable, I will also propose workarounds or alternatives.

We will look at a few of the tools in the order of the “product lifecycle”:
1. Code
2. Build/Test
3. Deploy
4. Release

Tools that are part of the “Code” phase

For the purpose of this post we are going to focus on tools that are natively offered by AWS as already mentioned and part of your CI/CD pipeline.

AWS CodeStar – Integration of projects

AWS CodeStar enables you to quickly develop, build, and deploy applications on AWS and provides a unified interface for your project. It provides you different templates that you can choose from to quickly start your project.

It allows you to manage your team, with permissions and integrates with your existing JIRA for issue management. It also integrates with your IDE (or with Cloud9).
You can also integrate with an existing Github repository.

AWS CodeCommit – hosted Git

AWS CodeCommit is a managed service for Git (just like Bitbucket, Github, Gitlab, …. It provides a hosted “git” environment that is encrypted at rest and can be accessed using usual Git clients.

AWS CodeGuru

Amazon CodeGuru is a developer tool that provides intelligent recommendations to improve code quality and identify an application’s most expensive lines of code. Integrate CodeGuru into your existing software development workflow to automate code reviews during application development and continuously monitor application’s performance in production and provide recommendations and visual clues on how to improve code quality, application performance, and reduce overall cost.

Tools that are part of the “Build” or “Test” phase

AWS CodePipeline – Tool to manage your CI/CD pipeline

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates.

AWS CodeBuild – Build tool based on containers

AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces ready-to-deploy software packages.

AWS CodeArtifact – artifact storage

AWS CodeArtifact allows you to store artifacts using popular package managers and build tools like Maven, Gradle, npm, Yarn, Twine, pip, and NuGet.

Tools that are part of the “deploy” phase

AWS CodeDeploy

AWS CodeDeploy is a fully managed deployment service that automates software deployments to various compute services, such as Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Service (ECS), AWS Lambda, and your on-premises servers.

AWS FIS

AWS Fault Injection Simulator (FIS) is a fully managed service for running fault injection experiments to improve an application’s performance, observability, and resiliency.

Tools that are part of the “Release” phase

AWS AppConfig (part of Systems Manager)

AWS AppConfig makes it easy for customers to quickly and safely configure, validate, and deploy feature flags and application configuration.

Wishlist

I’ve been able to gain some experience with the tools while working on a few projects, including cdk-codepipeline-flutter and here is a list of things that I believe could be improved.
My main focus here is on CodePipeline, as it serves as the glue between all of the other tools.

Native branch support for CodePipelines

Working with Jenkins and the MultiBranch plugin makes it easy to allow developers to quickly test and deploy code that they are working on using the CI/CD pipeline. Unfortunately, CodePipeline today does not allow automated branch discovery, so if you want to enable the automated execution of a pipeline for a branch, you will need to manually configure webhooks and then create a new pipeline (or delete an existing pipeline) when branches are created (or deleted). This is not easy to implement and it would be great if CodePipeline should natively allow creating a pipeline automatically for all branches of a linked Git repository.

Additional Templates and Best Practices

When setting up a CI/CD pipeline on AWS CodePipeline, this would be easier to use if additional best practices and templates would be available as part of the tool itself. AWS is starting to promote a new Open Source project called “Deployment Pipeline Reference Architecture“. this is a step in the right direction, but it needs to be expanded by other flavours of a deployment pipeline. Also the code examples need to be improved, made up to date and needs to include all languages supported by AWS CDK.
This is critical to allow an efficient adoption of the different tools.

Native integration of 3rd party tools

AWS CodePipeline should natively support integrations to other 3rd party tools that should be part of your CI/CD pipeline – e.g. security scans like Aquasec and Checkmarx.

Remove dependency for a specific AWS account and support Cross-Account deployments natively

As indicated in this AWS Blog post, the best practice for setting up a CI/CD pipeline and for managing your deployments is to use multiple, different accounts to manage your deployments. CI/CD should not be bound to an account level and this includes the management of your accounts that are able to access and configure the CI/CD tools.
Maybe a good option here would be the integration with the AWS Identity service. That might allow decoupling the CI/CD toolchain from the AWS account.

Up to date CodeBuild images

Docker Images provided by the CodeBuild team should be updated regularly and should support all “modern” toolkits. The open source project has some activity, but an issue for supporting newer Android versions is now open for some time…

Publishing options to the different mobile stores (AppStore, Play Store, Windows Store, etc….) should be possible

I’ve been looking at developing a mobile app using Flutter, but what I have not yet been able to achieve is pushing the created and build applications to the different app stores. Today, AWS does not support this natively.
You CAN integrate this with 3rd party tools like CodeMagic, but natively there is no option on AWS to publish your application.

Wrap up

This concludes the wish list that I have today for the existing AWS CI/CD tools.

Did I miss anything that you believe should be added?

Use the comments to give feedback or reach out to me on LinkedIn or by E-Mail!

Views: 426

How to pre:Invent – how Builders, Heros and UG Leader prepare for re:Invent – attending remotely and in person

re:Invent 2022 is approaching FAST, faster than you can actually take screenshots from the official homepage with the counter on it 🙂 We just crossed the “less than 20 days to go” and a lot of AWS community members are as excited as I am for the conference to begin.

In this post your are going to learn some tips & tricks from a few AWS Community Builders, AWS User Group Leaders and Heros (and of course from myself) about how to “pre:Invent” – “prepare for re:Invent” in order to best use the conference. I have attended re:Invent remotely as well as in person – and this year I am going to be back there in person.

Some of the heros, user group leaders & builders have attended re:Invent more than 10 times (and it only happened 11 times!) – so this postis a “source of experiences” – just as Corey Quinns post 🙂

The information that are included here were collected in less than a day – and this shows how #AWSome the AWS community is – thanks for your contributions (in no particular order):

Thorsten Höger, Markus Ostertag, Niklas Westerstråhle, Ganesh Swaminathan, David Bounds, Edmund Craske, Brian Tarbox, Mike Graff, Antonio Lagrotteria, Laurens van Gunst, Jennifer Bergstrom, Andrea Cavagna, Carlos Segundo del Castillo, Brian Pfeil

What’s the most exciting Keynote that we are expecting to see?

As all of the Keynotes are live-streamed in the attendees portal (and later made available on Youtube), this applies both to in-person and to remote attendees.

Personally I know that all of the Keynotes presented at AWS will be great and will have a lot of interesting content, as I’ve been fortunate to meet Nick Walsh at the AWS Summit Berlin. Now that I know one of the persons behind the Keynotes, I do understand how they are crafted, scripted and prepared with a high degree of customer input.

Still, the “most loved” Keynote with by my interview partners is the Keynote that Werner Vogels delivery on Thursday morning – and this is in line with my personal experiences. Werner always has the more “developer” and “builders” oriented keynote with more technical details, while at the same time putting his insights (and announcements) in context to the “broader” industry experiences and best practices.

The Adam Selipsky is second on the leaderboard, especially for the announcements that he, as the current CEO of Amazon Web Services (AWS) usually makes.

Last on our top 3 we have Peter DeSantis keynote – he delivers his Keynote on Monday evening (strange time for a Keynote) but its usually great fun to watch!

Most important information for builders attending re:Invent virtually / remotely

In general I need to admit that I’ve talked to a “biased” community – most of the persons I talked with are actually attending in person. But the pandemic and the “all-virtual” re:Invent in 2020 have proven that AWS is able to deliver a “great” virtual experience aswell. In 2021 I attended the “hybrid” re:Invent (where it happened in person in Vegas again) and was able to gain a lot of value out of it for myself.

Of course, not being in person reduces the “networking” possibilities that you have with other AWS enthutiasts and community members. But you can still learn a lot and invest into your professional career – and there are great reasons, like the aim to reduce your carbon footprint (@Brian) or maybe just the long travel time. Don’t feel left our – most of the sessions are going to be available online later.

The available sessions in the session catalog are always with a very high quality and share important insights into best practices as well as implementation details.

Register an account in the AWS Events portal. For your E-Mail adress, use an address that you can later identify (e.g. lockhead+reinvent2022@lockhead.info). That will help you to later identify and delete…messages that you get from sponsors 😉

What are your most important tips for preparing for the best re:Invent experience?

Plan your week – in the right time zone!
All of the “live” sessions (last week it was only the “keynotes” and a few “leadership sessions”) are going to be taking place in the Pacific Time Zone (PST). This means, 8 am PST translates to 5 pm CET – and thats a great possibility to meet “in person” within other members of your User Group and watch the Keynotes with a few pizzas & drinks.

If you are planning to attend recorded sessions, they are usually available the day after they have been given “live” – so the monday will be “quiet” for you.

Pick a focus topic, project or product that you are interested in – and find the topics in the session catalog that match your “skill level”, this is the session “classification” table:

Level 100Level 200Level 300Level 400
IntroductoryIntermediateAdvancedExpert
Sessions are focused on
providing an overview of AWS
services and features, with the
assumption that attendees are
new to the topic.		Sessions are focused on
providing best practices, details
of service features and demos
with the assumption that
attendees have introductory
knowledge of the topics.		Sessions dive deeper into the selected
topic. Presenters assume that the
audience has some familiarity with
the topic, but may or may not have
direct experience implementing a
similar solution.		Sessions are for attendees who are
deeply familiar with the topic, have
implemented a solution on their own
already, and are comfortable with how
the technology works across multiple
services, architectures, and
implementations.

What are our most important tips for the best re:Invent experience?

Meet in person for the Keynotes live stream if you can. That is really more fun than watching them alone remotely.

Don’t sweat it (thanks Edward!)- most of the content will be available on demand, you just need to find time to watch it – so talk to your team at work and to your manager to block some time thoughout the week for the talks you are really interested in.

Write Blog posts or Social postings with questions or remarks – and talk to Builders, Heros and other AWS Community members that are attending in person if you want specific questions to be answered by a service team!

Most important information for builders attending re:Invent in person in Las Vegas

What are our most imporant tips for preparing for the best re:Invent experience?

Bring good and comfortable shoes.

Know the campus. You are going to walk “A LOT” if you switch between venues in the campus.
The shoes that you were need to make you feel good!

Be “venue aware” when choosing the sessions – in 2018, I had a day where I needed to walk from the Venetian to the Aria and back three times on the same day – thats about 14 km on a single day!

Time is precious and limited.

Plan every day wisely:
– make time for the “hallway track” (Thanks Jennifer for explaining that saying to me!) -which means being spontanous and talking to other attendees.
– plan to be staying in one or maximum two venues per day
– plan your breaks, hydrating and meeting folks you would like to meet
– a few of us are prioritizing Chat-Talks and Workshops over sessions, others do not attend much sessions at all

Besides re:Play, there are tons of other receptions or parties accross the week. Plan to go there to network.

Pack light. Expect a lot of (cool) SWAG like this one or bigger things. You might need a lot of room in your suitcase 😉

What are our tips for the best re:Invent experience?

Prioritize networking possibilities over sessions. re:Invent is once in a year the best networking opportunity that you will get.
Don’t expect too much from youself every day – if we you meet someone to talk to, don’t feel forced to rush to the next session you had planned!

Attend the Keynotes. At least Werner’s (thursday morning) and Andys (tuesday morning).

Type down “things to look at later” on your phone – or you will actually forget the “most important thing” that you have learned during re:Invent 🙂

Regularly re-view the session catalog as new sessions are added on a daily or even hourly basis. Otherwise you might miss out on the most important one for your future career 😉

Which session are you most interested in/looking forward to?

This question was the most interesting one for me – as there is no “consens” across the group of Builders, Heros and UG Leaders that I talked to.
Everyone is different and has different interests – a few of us are going to not attend a lot of sessions and rather meet other builders and talk to them, a few are signed up for >10 sessions and can hardly choose their favorites – and others are focused on AI/ML sessions.

This is one of the things I really like about re:Invent – everyone attending will find “something” to learn, experience and take away – regardless of your skill level or role.

I was a little bit sad that none of my interview partners actually mentioned my own session, a DevChat, as her or his favorite session they are most interested in 🙂

COM307– Using CDK pipelines (in Java) to build a multi-platform Flutter app, Wednesday 12/30 at 1:30 pm PST at the EXPO

I hope to see a few of you there!

Let’s meet up in person!

For all of you that you are attending re:Invent in person – let me know in the comments or by mail – or by LinkedIn if you want to meet up.

I’m looking forward meet in person and have great conversations!

Views: 786

How to start your own AWS User Group aka Meetup?

In this article, you are going to learn about “HOW” to start and create your own, personal AWS User Group. You are going to learn about resources that will help you to get started and a few tips and tricks to get through the first few meetups.
The best thing:
These are all “real world” information that I’ve encountered myself in the last months when starting the “AWS User Group Bergstrasse“.

What is an AWS User Group / Meetup?

An AWS User Group – also known as “AWS Meetup” is a losely-coupled group of individuals that are intersted to connect, network, have fun together and…maybe…also talk a little bit about AWS, Amazon Web Services, Cloud Computing, Serverless, re:Invent and millions of other topics!
Usually, one to two “talks” (20 – 30 min, technical sessions) are presented in an event with AWS specific topics or experiences.

Most of the User Groups meet regularly in a 4-8 weeks cadence. Pre-COVID19, the User Groups where mostly “in-person” events. With COVID19, a lot of the User Groups moved to “virtual” events and not all of the User Groups have re-started “in-person” events.

Why should you start an AWS User Group / Meetup?

AWS User Groups are a great possibility to build up your professional network, to talk to other people that have the same interest or passion that you have – for AWS, AWS Services or any other topic you are interested in.
In the User Group meetings, you will be able to learn from other builders or engineers in your area (or maybe also from further away) – and you will be able to share experiences and improve your day-to-day work.

Wait..there is more…

Usually meetups are accompanied with drinks & food!

…and if you, as an User Group Leader, do things right, they might be “for free” because you have found a sponsor or host for your User Group 🙂

So how do you get started?

Just DO it!

Don’t wait or ask for permission.
Talk to your co-workers or maybe friends or other people in your network and the “Kick-Off” your User Group on a platform that you want to use to host your event.
I personally use Meetup.com and a lot of other User Group Leader do the same.
When you created you “public” group, start sharing and promoting it in your network on Twitter, LinkedIn or other channels.

Now, the users should start “registering” or “signing up” for your User Group.

Ideally, you would have a few people registered to get informed about new events by this stage.

After promoting your group, the next thing is to start planning your FIRST EVENT!

Your first event

Before inviting your User Group members to your first event, it might make sense to use a questionnaire with the “best day” to meet. I did that and got interesting results – so now, our User Group has chosen “Monday” as our “normal” day to meet.
Ask your User Group members about “interests” and “cloud usage” experience – that will help you to choose topics for the first sessions.

For your first event, the most important thing that you need is a location. Ask your employeer, a co-working space in your area or other locations that you can use to “host” your event. The AWS Community page has an FAQ that covers a bunch of additional ideas.

Don’t over-prepare -you can just get started “as easy as possible”:
– get “one topic” that will be discussed at the first event
– think about a “cool” way of bringing your members together – we did an “agile game” in our first event and that brought a lot of fun for all of us.

Cover some introductions in the first event, name tags, so everyone feels comfortable talking and approaching others.
But the most important thing is, as I already mentioned:

Just DO it!

Tips & Tricks for the first few meetups

Use the first event to find out the best cadence for your group and additional topics that the group members want to talk about.
We were able to find speakers within the group to talk about “starting” things and topics: AWS CDK, Terraform, Projen – the most important thing of these talks is to “start discussions” and get attendees to talk about their experiences as part of the “networking” session 🙂

Our second event was in a “Biergarten” and 100% focused on a good networking experience and building relations – that was a great evening! 🙂

Don’t over – plan, if you are able to secure the location for the next two to three events and have at least one speaker, you should be good to go.

Resources to help you

Me 🙂 – feel free to reach out to me on LinkedIn or through E-Mail.

AWS Community Landing Page
AWS User Groups Overview
AWSCommunity Support E-Mail

…and tons of other very helpful User Group leaders on LinkedIn, Twitter or other channels.

What do you do next?

After you started your User Group succesfully, please LET ME KNOW – I want to hear about your success story and how I can improve this article.

I will also help you to get connected to the AWS Community Management team which will then onboard you to the AWS User Group Leaders Slack, will be able to support you with potential speakers, AWS credits and SWAG! 🙂

Views: 1757

Building a Flutter application for Web, iOS and Android using a CI/CD pipeline on CodeBuild – #cdk4j

This post is a follow up to the last one where I showed a CDK project that can be used to build a Flutter application for Web.

Building a Flutter application (for Web) with AWS Lambda Function URL backend using AWS CDK Pipelines (written in Java)

In this post, we are going to expand our existing project on Github to be able to build an “apk” file for Android and a zip file for iOS. Before I can show you how this is possible, let’s start with some challenges that I’ve faced 🙂

The aim of this CI/CD pipeline is (not yet) to be able to push the apps into the AppStore / PlayStore for testing. That’s something we can add later 😉

Challenges on the way to a full CI/CD pipeline for Flutter on CodeBuild

While preparing this post I unfortunately faced more problems building up the pipeline than expected. Several problems.

AWS CodePipeline does not support M1 / macOS build images

Currently, AWS CodePipeline unfortunately does not provide the possibility to use the famous M1 minis on AWS as CodeBuild images. Tis his a real problem, as is makes it impossible to use CodeBuild for building iOS apps.
Running XCode on macOS is a requirement for building a Flutter app for iOS.
The M1 minis on AWS are currently pricey as hell for this use case – if you start ONE build you are directly charged 24 hours, even if the build takes only a few minutes! You need to actual get a dedicated instance, … – not usable for our use case of quickly building something for a side-project.
So we needed to find an alternative… read below! 😉

The current AWS CodePipeline standard runtimes are not able to build (modern) Android applications

The runtimes available and exposed by CodePipeline support Android runtime 29 – and the Docker images are provisioned using Java 8. Unfortunately, as of July 2021, the Android gradle tools (used by Flutter) require Java 11. I have created an issue in the corresponding Github (see here) but needed to find a workaround to move on – I think I’ve found one, but I hope that anyone reading this might have a better way or idea?

TypeScript dependencies on AWS Lambda can take your sleep

#awscommunity helps!

When implementing the trigger for the iOS App build (see more details below) I decided to “quickly” implement the HTTPS POST call using TypeScript – which turned out to be a bad decision 🙂
I had trouble getting the “axios” dependency that I am using installed correctly. I asked around, especially my fellow AWS Community Builders and got a lot of great tips and ideas (kudos to Martin and Matt). Martin had the right “stomach feeling – I was missing a “npm install”.

Matt enlightened me with the three different possibilities of making Typescript Lambda functions understand their dependencies:

1. Bundle dependency with your source code (can be achieved using esbuild)

2. Add a package.json and node_modules to the lambda function source – only a good idea if dependencies cannot be minified

3. Put the dependencies in a lambda layer

Matt Morgan

At the end, this challenge was especially difficult because I needed to add the required “npm install” in two places: In the “installCommands” for the CodePipeline itself and in the “installCommands” for the Flutter build step.

CodeBuild is slow, misses conditional steps and misses integrations – and does not easily allow multi-branch pipelines

While implementing the pipeline and solving the different challenges mentioned above, I lost some time because of CodeBuild being “slow” (>1min wait time during provisioining of the build containers). Thats understandable given the nature of the service, however it would be cool to have something like a “warm start” for a pipeline where the containers are re-used instead of re-provisioned.

There are no conditional steps – no chance to run a job only based on environment variables or anything similar. That made me implement a workaround. It would be cool to be able to use something like “branch-conditions” in the way Jenkins offers it.

CodeBuild offers only basic integration to SNS, but you cannot integrated a “lambda build step” to run the CodeMagic integration i nparallel to the flutter build job, but that is not possible, so I needed to run this “at the end” of the pipeline.

Another thing I’d love to have: multibranch pipelines. I needed to merge everything to main directly in order to test, because I couldnt figure out how my CDKPipeline would be able toe support multiple branches.

Reaching the goal: a full CI/CD pipeline running on AWS CodeBuild to build a Flutter app for Web, Android and iOS

Here is a diagram of the “final result” that I am presenting today:

Overview picture for CI/CD pipeline for Flutter App publishing to Web, Android APK and iOS zip

The “output” artifacts of our pipeline are:
– Flutter Web application (located on S3 and reachable through HTTP call)
– Flutter Android APK (that can be side-loaded on Android phones, located on S3 bucket)
– Flutter iOS App (that can be side-loaded on iOS phones, located within CodeMagic)

As the diagram shows, we needed to fall back to an 3rd-party, non-AWS service to be able to package the iOS application. After doing a quick “vendor selection” and a shortlist that included Bitrise and CodeMagic I decided to integrate CodeMagic in this example – because I liked the API more and it offers more free build credits/minutes. Setting it up took less then 5 minutes – it connects natively to Github and the set up of the Flutter pipeline is very easy.
The integration is set up using a Lambda function that calls the “start build” API.

How did I solve the challenges mentioned above?

The problem building the iOS image was resolved by integrating the external Service CodeMagic.

The Android Runtime Dependencies problems with Java 11 was resolved by switching to a custom docker container (Open source) – and then installing the requirements on top of it (npm/node, awscli, etc.).

What did you learn in this post?

In this post you have learned on how to expand the implementation of our CI/CD pipeline for an example Flutter application to not only building a “web” application, but also building an Android APK and an iOS zip file.
You have also seen an extension and integration of the Codepipeline with SNS for notifications and those events being picked up by a lambda function to trigger an external HTTPs API.
This is a major step – with this pipeline we are able to publish our application for three different “platforms” without a single code change – and it will all happen completely automatically!

I’d be glad to get your inputs into my Github repository as a pull request or just as comments on the project itself.

Next steps

Further expansions needed to this project:
– CodePipeline already has a SNS topic that it reports to – but right now the build iOS / Android App packages are not exposed anywhere – the idea would be to publish to an SQS queue the name of the APK file and the CodeMagic Build Id – and have a lambda function that is triggered by the queue update a link on the example application to download the newest version of the app 😉 Today, we need to retrieve both from S3 / CodeMagic itself
– use the CloudFormation Exports of the Lambda functions in the Flutter application instead of hardcoding the URLs for the Lambda Function URLs- enhance security for Lambda Function URLs
– add CloudFront in front of S3 to allow HTTPs connections to the Flutter App
– enhance CI/CD pipeline to package Windows App using Flutter
– enhance CI/CD pipeline to push created apps to App Store / Play Store

Feel free to contribute and add your contributions to this project into my Github repository.

Views: 3139

Building a Flutter application (for Web) with AWS Lambda Function URL backend using AWS CDK Pipelines (written in Java)

Wow, this is a long title 😉

In this post I am going to use CDK Pipelines to build a demo Flutter application hosted on AWS S3 with a Backend powered by AWS Lambda (using Function URLs).
The CDK code will be in Java, the Lambda functions in Typescript and the WebApp in Dart. Why? Because I love trying out things 🙂

The code used here is not production ready and does not fulfill required security best practices! 🙂

The CI/CD pipeline

The CI/CD pipeline for this project uses CDK Pipelines and that means it is build on top of AWS CodePipeline (which under the hood uses CodeBuild, CodeStar and other services to be functional).

It consists of different stages that build and deploy the corresponding part of the application:
– one stage for each lambda function
– one stage for the build and deployment of the Flutter application

The stages required by the CDK Pipeline to update itself are automatically added but not part of our code:

public CdkPipelineStack(final Construct parent, final String id, final String branch, final StackProps props) {
		super(parent, id, props);

	String connectionArn = "arn:aws:codestar-connections:eu-central-1:xxx:connection/xxx";
	final CodePipeline pipeline = CodePipeline.Builder.create(this, getCodepipelineName(branch))
			.pipelineName(getCodepipelineName(branch)).dockerEnabledForSynth(true)
			.synth(CodeBuildStep.Builder.create("SynthStep")
					.input(CodePipelineSource.connection("lock128/cdk-codepipeline-flutter", branch,
							ConnectionSourceOptions.builder().connectionArn(connectionArn).build()))
					.installCommands(List.of("npm install -g aws-cdk" // Commands to run before build
					)).commands(List.of("mvn test", "mvn package", // Language-specific build commands
							"npx cdk synth", // Synth command (always same)
							"bash start_codecov.sh"))
					.build())
				.build();

	pipeline.addStage(new CheckAgeLambdaStage(this, "DeployCheckAgeLambda"), getCheckAgeStageOpts());
	pipeline.addStage(new PaperSizeStage(this, "DeployPaperSizeStage"), getPaperSizeStageOpts());
	pipeline.addStage(new CalculatorStage(this, "DeployCalculatorStage"), getCalculatorStageOpts());

	PolicyStatement flutterDeployPermission = getDeployPermissions();
	CodeBuildStep buildAndDeployManual = CodeBuildStep.Builder.create("Execute Flutter Build and CodeCov")
			.commands(getFlutterBuildShellSteps()).rolePolicyStatements(Arrays.asList(flutterDeployPermission))
			.build();

	pipeline.addStage(new FlutterBuildStage(this, "FlutterBuildStage"),
			getFlutterStageOptions(buildAndDeployManual));

}

This is the definition of the CI/CD pipeline, it uses our Github repository as the source of the code and automatically starts after a push to the repository on the main branch.
The “Flutter Build Stage” is the one that currently builds the Flutter web application, deploys it and makes it available to the end user. Going forward, to make best use of Flutter, we would need to expand this stage to also be able to build an iOS application, an android application or an application for any other platform supported by Flutter. As a “goal” I would personally also want to extend this stage to be able to publish the apps to the corresponding stores (App Store, Play Store, Windows Store, …) – Thanks to my friends at cosee for the help and guidance around this process!

The architecture diagram of the application

What we are using to show-case the usage of AWS CodePipeline, Flutter as an application and AWS Lambda Function URLs as backend is not really an “application” – but it can do dynamic things and it can easily be extended to include a database backend, etc.

Infrastructure as Code using AWS CDK in Java

In this section you are going to have a look on the CDK code required to provision the infrastructure on AWS.
We are using AWS CDK written in Java – and because of that Maven as a build tool (Maven is the default tool for CDK projects – I’ve already used Gradle as build tool and that works in the same way.

The possibility of writing Infrastructure Code in Java is a great thing because it gives us the option to build on top of our existing skills – and I’ve written enough lines of Java in my career to feel comfortable using it to provision the infrastructure.
This is one of the best things in CDK: You can write your Infrastructure code in Java, Typescript, Python, … – and that helps us to build teams that only have “one” language as a “core skill” – one team might choose to develop in Java, anotherone in Typescript, another team could use Go – this allows the teams to build up mastery in a specific language!

In our example however, we are not making use of this possibility – I’ve choosen to rather go the opossite way: Combine a few languages, just to show that it works 😉

Stacks in the Example Project

The CDK code consists of four “stacks” – each of the Stack representing one “component” in this application.
In our example these four stacks are part of one CDK Application & one CodePipeline. In bigger projects, you might want to split these out into seperate applications – which introduces a lot tof things to consider (e.g. how do they fit and work together, etc.).

While writing this post, the four stacks combined are 129 lines of source code. With the help of the CDK Constructs that are being used this translates to over 1k lines of code in CloudFormation. We are only using L2 constructs here – there is way more constructs available that you can use in the Constructs Hub and also a lot of guidance regarding the usage of CDK over at CDKPatterns.

CDK Stack that provisions the infrastructure for the Flutter hosted website

Making a S3 bucket available to host our Flutter application becomes a very short piece of Java code as shown in the picture above.

Lambda functions behind Function URLs in Typescript and Python

This was definately one of the most awaited announcements in the Serverless space this year: The GA of the “Function URLs” for Lambda on AWS – and this is the reason for me using these as a backend in this showcase.
With this announcment, it is possible to directly expose your application running on AWS Lambda behind an HTTPs endpoint! Without an ApiGateway, Proxy, …
Provisioning the infrastructure for the lambda function with the function URL functionality activated is only a few lines in CDK:

CDK Stack for the Check Age Lambda function with the activation of the Function URL

These Lambda functions will now horizontally scale without us as a developer getting involved. More details on function URLs – there is a lot of good posts on it around like this one or this one.
Around scalability, fellow community builder Vlad has written up a great guide around scalability for containers on his website.

Web Single Page Application built using Flutter and the benefits of using Flutter

Flutter as a multi-platform, developer driven tool gives a lot of flexibility. With a single code base, you are able to publish your application to various targets. In this example, we are using the target platform “web” – which compiles the Dart code to a single page application.

This application is automatically aware of the size of your screen and is interative – which is another cool thing that Flutter takes away from you as a developer. A lot of organizations use Flutter today and the cookbook gives you an easy and good start into developing Flutter applications.

Our example application has three input fields that take input and pass it back to our Function URLs – and then automatically update a Text Widget with the results of the Function URL call. This implementation will work on all platforms.

What did you learn in this post?

You have learned how easy it is to provision AWS infrastructure using AWS CDK. You have also seen that you can easily combine different programming languages in a single CDK application and got an experience on how a CI/CD pipeline can help to automatically deploy our application using AWS CodeBuild.
In addition to that, you have looked at Flutter as a multi-platform development tool.

I’d be glad to get your inputs into my Github repository as a pull request or just as comments on the project itself.

Next steps

Further expansions needed to this project:
– use the CloudFormation Exports of the Lambda functions in the Flutter application instead of hardcoding the URLs for the Lambda Function URLs- enhance security for Lambda Function URLs
– add CloudFront in front of S3 to allow HTTPs connections to the Flutter App
– enhance CI/CD pipeline to package Android App using Flutter
– enhance CI/CD pipeline to package iOS App using Flutter
– enhance CI/CD pipeline to package Windows App using Flutter
Feel free to contribute and add your contributions to this project.

Listen to Werner Vogels talking about the benefits of CDK

Views: 2815