AWS re:Invent 2018 — Day 2 — some patterns emerging :-)

Day 2: “No rest for the wicked”

I started early and I “thought” I had a plan :-)

“Stay hydrated, bring Advil with you, meet some people, learn about what others are doing, their challenges, their wins, and yeah, try to eat healthy when you can …”

And Day 2 did not disappoint ..

So what did I learn from the AWS:ReInvent Attendees ?

1. Similar to Day 1, most of the attendees I spoke to, are just getting started on their Cloud journey.
2. I learned from a handful of attendees, that their Multi Cloud is not the result of well-designed and carefully measured plan. In most of the times it was due to an M&A (Mergers & Acquisitions) or a case where one BU (Business Unit) decided to use a different Cloud Provider for different but valid reasons (Remember that not all Clouds in all regions are homogenous)
3. There are many dimensions to Multi Cloud and most of the time, people(including me) are not crystal clear about what dimension, they are talking about (more on this later …)
4. Some have accepted the fact that you need different brokers for different applications and are surprised that Solace can push events to your browser right from Solace PubSub+ , published by a JMS or AMQP client — I showed them the PubSub+ Try Me CodePen and they love it and wanted to follow up
5. No surprise that when you say event broker, pub/sub, they immediately say “oh just like SQS ? and SNS ?” However, when you start talking about the message exchange patterns you need your event broker to support in order to service you EDA (Event-Driven Architecture) in an enterprise environment, you get some interesting follow up questions and they switch to ‘active listening” mode
6. I was also surprised, but maybe I don’t have a big data set, that most of the attendees knew what Kafka is and are using it for what it was built for. Not a multi-purpose event broker

So what did I learn from Day 2 Sessions ?

CON360: From Monolith to Microservices , And All the Bumps along the Way (slideshare)

“Applications built on a microservices-based architecture and packaged as containers bring several benefits to your organization. In this session, Duolingo, a popular language-learning platform and an Amazon ECS customer, describes its journey from a monolith to a microservices architecture. We highlight the hurdles you may encounter, discuss how to plan your migration to microservices, and explain how you can use Amazon ECS to manage this journey.”

So what did learn from this session:

1. It’s a good reference framework (people, workflow, technical) to start. The Ops Engineer for Duolingo explained it well and was transparent and to the point
2. Make it a dev team pain/opportunity and things will work. Don’t expect to only have your ops on call. Devs should be on call too :-)
3. Invest, invest, invest in your deployment workflow — it’s an obsession of mine, and I am lucky to have engineers that are equally obsessed working in the Solace Cloud team.

Things I expected them to talk about:

1. How to break the monolith, services boundaries etc…
2. Events exchange ? What happens when you move from intra-process communication to inter-process communication (microservice to microservice communications…)

DEV319: Continuous Integration Best Practices (slideshare not available, coming soon)

“Today, more teams are adopting continuous integration (CI) techniques to enable collaboration, increase agility, and deliver a high-quality product faster. Cloud-based development tools such as AWS CodeCommit and AWS CodeBuild can enable teams to easily adopt CI practices without the need to manage infrastructure. In this session, we showcase best practices for code reviews and continuous integration, drawing on practices used by Amazon engineering teams. We’ll incorporate demos to not just explain the practices but show you how.”

1. I was looking forward for this session, but I should have read the description, this was a session about AWS tool chain CodeCommit, CodeBuild etc…
2. They had a live demo, but it was too easy :-), too simple, well timed :-) I was hoping to hear from one of the Hipster Enterprises about how they actually do this, their best practices, their pains, their wins, you know what I mean, I want the real deal (more than 10 live deploys per day)
3. Nothing about the necessary or sufficient architecture to support a continuous delivery model.
4. They oversimplified it: continuous integration is a building block of continuous delivery but not enough, am I right ?
5. Anyways, I appreciated the time and effort, and I learned some stuff :-)

Time to go to bed now, see you at Day 3