Category Archives: Uncategorized

How to build a AWS CodePipeline to build and deploy a Lambda function written in Scala

After reading through many tutorials and playing around with tools and concepts I finally managed to build an automated AWS based deployment chain, which deploys my Scala code into a Lambda.

This is what I have in the end: When I push my code changes into my github repository, AWS CodePipeline reacts on the change and downloads the sources into an AWS CodeBuild environment. There everything is built using sbt and the build artifacts are stored in S3. When that’s done AWS CloudFormation takes over to deploy the changes. This creates or updates a Lambda function to use my latest Scala code for event handling.

The code is just a basic http request handler that takes a piece of json containing a “name” key and responding with a hello string using the key’s value in the response body.

I started to work my way up from this tutorial about running Scala in Lambda. But instead of reacting to an S3 event I wanted the handler to react on a HTTP request with some json in the body. Luckily Yeghishe provides some code to handle those requests in Scala.

So I ended up with this MyHandler.class

package example

import io.github.yeghishe.lambda._

// handler io.github.yeghishe.MySimpleHander::handler
// input "foo"
object MySimpleHandler extends App {
  def handler(name: String, context: Context): String = s"Hello $name"

case class Name(name: String)
case class Greeting(message: String)

// handler io.github.yeghishe.MyHandler
// input {"name": "Yeghishe"}
class MyHandler extends Handler[Name, Greeting] {
  def handler(name: Name, context: Context): Greeting = {"Name is $name")
    Greeting(s"Hi ${}. Have a nice day!")

For sbt to build this there are some external library dependencies to manage. Including also the AWS dependencies my build.sbt looks like this now:

import sbt.Keys.libraryDependencies

javacOptions ++= Seq("-source", "1.8", "-target", "1.8", "-Xlint")

lazy val root = (project in file(".")).
    name := "lambda-demo",
    version := "1.0",
    scalaVersion := "2.11.4",
    retrieveManaged := true,
    libraryDependencies += "com.amazonaws" % "aws-lambda-java-core" % "1.0.0",
    libraryDependencies += "com.amazonaws" % "aws-lambda-java-events" % "1.0.0",
    libraryDependencies += "com.amazonaws" % "aws-lambda-java-log4j" % "1.0.0",
    libraryDependencies += "io.github.yeghishe" %% "scala-aws-lambda-utils" % "0.0.2"

assemblyMergeStrategy in assembly :=
      case PathList("META-INF", xs @ _*) => MergeStrategy.discard
      case x => MergeStrategy.first

This adds three amazon libs to let the code run in the AWS environment and the Yegishe’s lib for the request handling. I also had to add a plugins.sbt into the root/project folder containing just the line

addSbtPlugin("com.eed3si9n" % "sbt-assembly" % "0.12.0")

This gives my sbt the ability to execute an assembly command, which builds a jar containing my code an all the needed libs in it. At this point I was able to directly upload my jar into Lambda and run it through the web interface.

But I wanted a fully automated build pipeline. Following this amazon tutorial I created a CodePipeline with four steps. In general everything was straight forward from here, but there still where some traps for me to fall into, since this tutorial assumed JavaScript code to be executed in Lambda.

I had to change the buildspec.yml to deploy my assembled jar file correctly.

version: 0.1

      - echo Build started on `date`
      - echo Run the test and package the code...
      - sbt compile
      - sbt assembly
      - echo Build completed on `date`
      - mkdir deploy
      - mkdir deploy/lib
      - cp target/scala-2.11/lambda-demo-assembly-1.0.jar deploy/lib
      - aws cloudformation package --template-file samTemplate.yaml --s3-bucket testbucket-77 --output-template-file NewSamTemplate.yaml
  type: zip
    - deploy/lib/lambda-demo-assembly-1.0.jar
    - NewSamTemplate.yaml

In the tutorial the call to “aws cloudformation” is done in the install phase before any code is being actually compiled and packaged. So the package command only puts the NewSamTemplate.yaml and all the source files into my S3 bucket. In the end I always ran into ClassNotFoundExceptions in Lambda, since it could not find my handler class. The compiled and packaged build artifacts where actually stored in another S3 bucket, which was created by AWS CodeBuild.

Moving the package command into post_build ensures that it is called after everything is build. It will than upload everything in respect to the CodeUri value in the samTemplate.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: An AWS Serverless Specification template describing your function.
    Type: 'AWS::Serverless::Function'
      Handler: example.MyHandler
      Runtime: java8
      CodeUri: deploy
      Description: ''
      MemorySize: 512
      Timeout: 15
      Role: 'arn:aws:iam::362856109184:role/service-role/lambda_basic_execution'

Here I defined the code artifact location to me the deploy folder. In the buildspec above I made sure this folder exists and that the assembled jar file will be in a lib folder inside that deploy folder. I learned that Lambda can only access jars if they are in a lib folder in the final deploy zip.

Inside the CodeBuild environment I also needed a Docker image, that had sbt and aws-shell on board. The first to build the Scala code and the second to execute the aws cloudformation command. Since I could not find a prebuild image I created my own one and pushed it into dockerhub. You can find it here 7oas7er/sbt-aws-shell.


Bringing Kanban into Marketing


Three weeks ago one of our marketing teams asked me for some consulting about increasing process transparency for themselves, their stakeholders and their management. Since Monday we are running a Kanban implementation and having Daily Stand Ups in front of what became the company’s biggest Kanban board. In this post I will show you how we got that far and share some first observations with you.

The Team

Part of our marketing department is a team which is taking care for the planning and running of internal and external events and for creating and delivering educational content like webinars. This “Event Team” is responsible for the success of more than 500 events each year many of them being big customer marketing events. The work of the Event Team has great value to our company and the company knows the team is doing a great job.

Nevertheless the team asked for a workshop to talk about the way they work. They had the feeling some things could be improved on the team’s process and workflow level. In an initial meeting with the team they worked out, that their biggest pain is a lack of transparency. They are all working on many things at the same time, but they miss the big picture.

Who works on what? Who needs help? What is left to do to prepare event x? They want to have this transparency for themselves and for their stakeholders and managers. They want to be able to explicitly show how much stuff they get done and what kind of value they deliver to us all. So we discovered what is called a “source of dissatisfaction” in Kanban and what would give us a goal for improvement from now on.

Getting Buy In

After that meeting I had ideas how to tackle the transparency problem. I would recommend to the team and the team’s management that we set up a Kanban system where we start to visualize the flow of the team’s work, thus making transparent who works on what, what the work is and where the work lies.

Introducing Kanban to a team that has no explicit Agile background is not a small change. I knew it would affect how the team members interact with each other, it would call for even more self-organization and for the team to take ownership of their process. For that change, the related time and cost investment and the risk of failing I wanted to have an explicit buy in.

I met with the department lead and spoke with him about the team’s request for help and my ideas for supporting the team, got his go and promised to keep him updated. For the team I scheduled a short Kanban training. In 90 minutes I introduced them to the concept of evolutionary change, the J-Curve effect, the principles and practices of Kanban, the idea of creating a physical team board and the investments and risks evolved. I got their buy for the change and I planned the next step: Creating a Kanban board.

The Board Building Workshop

A week later I met the team to create the team’s Kanban board. I put some blank sheets of flip chart paper on the meeting room’s wall to scribble board designs and I introduced them to our approach of designing their Kanban system. Here are the steps I’ve prepared for them on another flip chart.


Starting with work item types we took a lot of time to discuss the work flow and the discovery process was very iterative. For instance we initially defined the work item types “Offline Event” and “Online Event” as the team said it was doing two different things here. During the work flow discovery we found that cards of both item types would flow the same way and we decided to have just one work item type “Event”.

The work flow we found for planning and running events in this team came down to “Inbox -> Briefing -> Preparation -> Running -> Finishing”. Inbox is of course the place where new event cards come in. Here the team needs to prioritize the events to make sure they prepare more important and more complicated events first. The first thing happening to each event is a briefing session with the event’s stakeholders. There goals, content, audience, expectations and so on are identified and documented by the event team.

An event card will leave Briefing if the team knows what to prepare for the event. The Briefing column is very similar to a task planning column of a software development team and the briefing itself reminds me of a Sprint Planning II in Scrum. The column Preparation has the typical three sub-columns on a task level To Do, Doing, Done. No surprise the work of the Event Team is mostly focused around preparation of events. After an event has been prepared, meaning that all preparation tasks went to Done, the event can take place. The card sits in Running. Finally for some events there is a debriefing or feedback session, which occurs in the Finishing column.

It took us 90 minutes to finish our board design. We did not make it through points 3 to 5 of the system design flip chart but I was fine with it as the problem to solve is the lack of transparency and for that having a visible work flow might be a good solution already. The last thing I wanted to know then was how big the real physical board would need to be. I asked how many events they are currently working on so I could multiply the amount with the sticky note size to get the board dimensions. I was really surprised when the team discovered more and more events they are currently preparing. I think we stopped counting at 30. Enough for me to know that we would need a very big board 😉

We used the team’s lockers as the board background every locker being a column of the Kanban board. I also scheduled a Daily Stand Up every morning with the team in front of the board.

The first week

Now after some days the board fills up with more and more tasks. Some events are “delivered” each day. They go into the Running column and into Finishing the next day. The team uses this to briefly give an update on how the event went. New events are entering the board from left and are pulled into Briefing and Preparation. On the task level the team is having spontaneous discussions. Sometimes someone adds additional information that have not been transparent to all, sometimes a task is trashed as the team notices it is not necessary to do it.

We already faced the limits of our current board design. It seems we are in need of a swim lane for tasks that are not related to a special event and I have the feeling we need one or two additional columns for events that are waiting to be prepared after the briefing and that are waiting to be run after the preparation. We also need to find a way to easily visualize who works on what for about 100 task cards. I scheduled a board iteration meeting and will post about the evolution of the Event Team’s Kanban system.

On other thing that took me some time to realize is that a plain optimization of lead time might not be an appropriate goal for this team. Most of the events they are preparing are scheduled for a fixed date in the future, so most of them have dead lines. For this team delivering an event in March that is expected to take place in April does not make sense, though the lead time would be less. If we seek for any optimization here I think we have to focus on the task level in the event preparation phase, but I’m not sure what the next goal could be and what kind of measuring will support us here. Any ideas and feedback welcome.