Containers were this awesome technology that ushered in the Cloud era and with a lot of new FaaS tools coming along, companies are wondering if they should jump the container ship altogether. As it turns out, containers definitely have value in Serverless. In this session we will take an existing containerized app and move it into AWS Fargate, look at the cost of running it, and how we can monitor it.
Using serverless requires us to change our mindset on how we build apps and requires us to unlearn things we learned building apps in the past. At AWS re:Invent I got a chance to do a VMware Code session and talk about how we took part of our ACME Fitness Shop and transformed it into serverless functions with AWS Lambda.
As a developer, I always thought that security, like documentation, would be done by someone else. While that might have been true in the past, in today’s world that model no longer works. As a developer you’re responsible for the security of your app. Security in this case should be seen in the broadest sense of the word, ranging from licenses to software packages. A chef creating cheesecake has similar challenges. The ingredients of a cheesecake are similar to the software packages a developer uses. The preparation is similar to the DevOps pipeline, and recipe is similar to the licenses for developers. Messing up any of those means you have a messy kitchen, or a data breach!
Trusting Your Ingredients - What Building Go Apps And Cheesecake Have In Common.
In this lightning session at GopherCon 2019, I got the chance to talk about two things I love. Cheesecake and Golang! As a developer, I’ve written code and built apps, and I realized that building apps and creating a cheesecake have a lot in common. In both cases you need to have the right ingredients, you need to trust your suppliers and have transparency in your production process. In this talk, we’ll look at how you can, and why you should, know what is in the app you deploy.
In today’s world everyone is building apps, most times those apps are event-driven and react to what happens around them. How do you take those apps to, let’s say, a Kubernetes cluster, or let them communicate between cloud and on-premises, and how can developers and non-developers work together using the same tools? Let’s break down the title a bit…
Not too long ago Flogo introduced a new Go API that allows you to build event-driven apps by simply embedding the Flogo engine in your existing Go code. Now you can use the event-driven engine of Flogo to build Go apps while using the activities and triggers that already exist and combining that with “regular” Go code. In one of my other posts, I built an app that could receive messages from PubNub and for this post, I’ll walk through building the exact same using the Go API.
I can hear you think “Part 2?! So there actually is a part 1?” 😱 The answer to that is, yes, there most definitely is a part 1 (but you can safely ignore that 😅). In that part I went over deploying Flogo apps built with the Flogo Web UI using the Serverless Framework. Now, with the Go API that we added to Flogo, you can mix triggers and activities from Flogo (and the community) with your regular Go code and deploy using the Serverless Framework.
Building microservices is awesome, having them talk to each other is even more awesome! But in today’s world, you can’t be too careful when it comes to sending sensitive data across the wire. Last week I was at PubNub for a Meetup where, together with Jordan Schuetz and Nicholas Grenié, we spoke about cool things you can do with PubNub. One of them is using PubNub as a messaging layer to have your microservices, built with Flogo (duh), talk to each other in a secure way. In this post, I’ll go over the steps to build those microservices and hook them up using PubNub.
I spoke at a Gopherfest meetup about the Go Programming Language. Together with an awesome colleague (Miguel Torres) we talked about Project Flogo and the lessons we learned building it.
