First experience of AWS Summit London 2019
13 May 2019 Comments off
Reading time:
15 minutes
Word count:
3357
First experience of AWS Summit London 2019
What problem was I looking to solve?
I wanted learning more about the AWS services beyond EC2, S3 and EBS #0. I went to London’s Excel to experience Amazon’s personality, it’s brand and also to be inspired by the technology.
For starters there is Elastic Cloud Compute (EC2), Simple Storage Service (S3) and Elastic Block Storage (EBS)
Also check out Simple Queue Service (SQS) for managed end-to-end messages across queues that permit scalable decoupled microservices
and Simple Notification Service (SNS) for managed, highly available, scalable publish and subscribe messaging.
What area of focus was I was most interested in?
Obviously, I heard a lot of about serverless in the last couple of years. Technically, it is Framework (function)-as-a-Service (FaaS), where the architecture of a cloud application can be thought of a lattice of singleton functions, which respond to events. These functions are ephemeral in lifecycle and provide the illusion efficient execution without the complexity of network configuration and provisioning of servers.
In plain English, you as the customer, the developer, have the ability to execute programs on a rented server cluster without the responsibility and the cost of management of the hardware: hence the word “serverless”, but this note is a clever illusion.
So to answer the question, I wanted to understand were AWS Lambdas fitted into a traditional EC2 VPC infrastructure.
My travel day started the 7:31 am train at Milton Keynes Central to London Euston, a fast train, I know very well. Travel into the big city is not pleasant. #1
So sadly, I missed a good portion of the keynote with the AWS top brass. Still, I was knocked back by the turnout, there were literally thousands of people at the Excel Centre in East London. I recalled instantly being in this building once before, it was the London Olympics of 2012. #2
Back to the AWS Summit, after making it through the throng of registration, I saw the exhibition hall space, which was big. Let me give you the sense of this conference, remember AWS Summit is a one day conference organised by Amazon. Registration was FREE and attendance was FREE. I haven’t got it officially confirmed by organisers, because I am not PRESS. The attendance was 6000 to 7000 people according to my source #3
, and it could have been actually more. So that is twice the size of Stefan Janssen’s Belgium Devoxx over 5 days, the worst attended San Francisco JavaOne conferences in this decade 2010 to 2015, between the three hotels was probably close to this attendance figure, but no one from Oracle ever released to me out official attendance figures. Best of all, at AWS Summit, the food and coffee and the post-event evening beer was entirely free, when it was put out. If you are getting the impression that I was very impressed, then you would be entirely correct, because I, from your point of view, might appear to be a moany-hole, especially on many subjects, but I did not act so silly about cutting off one’s nose to spite one’s face.
The security guards refused to let me go into auditorium with the big keynote, and they were quite right to, the auditorium was full to the rafters. They gently pointed me to the remaining theatres, 1-7 of them in order to watch the streamed keynote in the overflow rooms. So I did that. At previous JavaOne conferences, I felt peculiar, because usually vendor marketing talks were held up to be derision by delegates. Conference goers want to hear about technology, the next bleeding edge, not by business executives talk. Witness the many bizarre IBM keynotes, many of them, where people walked out or slept in. However, this was Amazon’s big conference, so of course, what did I expect here? They were going talk about EC2, Fargate, RDS and GPU and whatever that Amazon Web Services will did. Yes it was a marketed conference from Amazon, but you know I did not feel that I was marketed at, as a conference after thought, they didn’t need to, they have had me, you and us from the moment of free registration and turning up for the day. In other words, the pressure to product-market was off.
What sessions did I attend?
I attended at least four talks during the day.
Running Containers on AWS
The first session of the day, was Running Containers on AWS, by Massimo Re Ferre, principal AWS advocate and Nicolas Trésegnie, guest speaker from Super Awesome. This talk was about AWS infrastructure to run different types of containers. We have known for a long time that it is straightforward to spin up Docker in own EC2 instances, and we can get a Docker Swarm cluster with all the niceties, but it is fantastical DIY. Ok yeah. We can Terraform it. Sure. Re Ferre presented an overview of the trade-off between ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service). With ECS, this designed for Docker image running on an official Amazon infrastructure. EKS is a Kubernetes side. ECR (Elastic Container Repository) is Amazon’s take on the repository, it’s own Docker Hub. As an architect, ECS with ECR makes cost-saving sense, because data ingestion from an outside repository into your VPC could be charged. As far as I understand it at the time of writing ECR and ECS are designed to work together seamlessly, it is possible to pull Docker Hub images into ECS through the task definition. Massimo talked in depth about AWS Fargate. I think this is very interesting concept, where you can have Docker image container and hand it over to Fargate, which executes the task on Amazon’s own infrastructure outside of your VPC, but you are still charged for the CPU, but you never see the actual EC2 instances. It’s feels very strange and as an architect, how can I independently advise my clients and customers about Fargate’s veracity #4. It you trust AWS Lambdas already, then yes, go for it, especially if you don’t care for orchestration and you definitely never want to SSH into your task definition. If you do want to SSH to server then, Fargate is not a solution for you, right here right now.
EKS is interesting solution for Kubernetes in Docker officially on Amazon. The big benefit is that Amazon takes care of the control plane. Your platform team need not be responsible for management of pods. We customers of AWS, your platform team are responsible for the data plane. Unlike Fargate, platform can SSH into EKS worker nodes, usually with the username ec2-user on EC2 AMIs provided you allocate the appropriate key-pair to the nodes beforehand. Be aware it does USD 0.20 per hour for hosting each cluster. Sadly, it precludes learning solo engineers and EKS is always the current stable release version. Amazon does not support the unstable Kubernetes.
I was very impressed with the Super Awesome presentation. The guest speaker talked about the their migration from a Linux VPS and data centre for the startup to Docker containers. He talked about the migration to AWS ECS and ECR. Nowadays, Super Awesome are fully into Kubernetes and using EKS. Nicolas Trésegnie is a sound guy with a business of protecting vulnerable children from the Internet horrors. Well played!
CI/CD on AWS
I grabbed a quick lunch, which was FREE. Thanks Jeff! I went back to the massive auditorium theatre and saw the very beginnings of the CI/CD on AWS, by Danilo Poccia. It was an interesting take on CI services for engineering teams, heavily focused on the AWS Lambda. When the speaker mentioned infrastructure-as-code (IaC), I thought he was going to delve in to Terraform or Ansible, but it was AWS CodeBuild and CodePipeline and CodeDeploy solutions. Your mileage will vary as it did with the marketing so I bailed this session. These are specific tools for one cloud platform and it you want to be portable then it is very difficult in 2019 to use independent serverless tools, libraries and programming languages. I welcome your feedback if you have a different insight and experience in this matter.
Modern Application Architectures
I went to exhibition hall to talk with vendors for a while. I did venture very briefly into Modern Application Architectures in the auditorium again with Ian Massingham. It started out as a very high level overview of known application architectures. When the slides are talking about driving adoption and migrating data centre applications and infrastructure to AWS, then I knew it that I would not get much value out of the talk. I already know that AWS is a key differentiator in the marketplace, because it was the first to deliver commodity based cloud-computing. (Yes. I also know that Sun Microsystems and others failed to imagine the correct financial business model that was Elastic Cloud Compute.) AWS and Amazon are heavily invested into the Java and as we know they have their own OpenJDK distribution #5. I left this one and instead went back to the exhibition to see the AWS Architects space (See below).
Are you well architected?
I spent so much time with the AWS Solution Architects that I only just caught the second half of a session, ironically: Are You Well Architected? by Philip Fitzsimons. I thought the framework and the ideas were very well presented. I arrived in the middle of the Reliability pillar of the talk, which was just typical. How does an architect deliver an infrastructure and system that tolerates failure? How does one typically auto scale and mitigate disruptions? There was loads of suggestions for this one. I wondered how many folks out there in the captive audience were implementing “game days”. I suspected that many were still into the beginnings of cloud-native engineering , just starting their own digital transformations and only some rare diamonds had good knowledge of components, micro services and platforms. I was annoyed that I missed the Security pillar of this talk, but the other concepts including cost efficiency and performance were covered by yet more Amazon services. Look, I totally got the point, if you haven’t switch of Cloud Watch and were unable to see the logging information of your EC2 instances, then, indeed, there is a problem, Houston. This talk was one of my favourites and it really kicked the TOGAF and Zachman Framework zeoletry nonsense into touch. I really liked the idea of an evolutionary architecture #6 (a compromise to the sustainable architecture. Evolve it first, then sustain it) and also automate it first and also drive data through your architecture (blue/green deployments and canaries). I hoped this talk was recorded!
Fault Tolerance Architecture and of course how to develop self-healing system through the concept of Evolutionary Architecture. It is also essential to consider the terms Bit Rot and Architectural Erosion.
Sadly, this talk clashed with the other session that I wanted to see, Java on AWS, but perhaps, you can understand why I chose the well-architected one.
Serverless functions deep-dive
I watched 18 minutes of this talk about Serverless functions deep-dive and the AWS Lambda by Daniel Pocca. I was attracted by the Lambdas knowledge. It started out fairly well with the idea of functions, and the fact, that you only pay for the compute-time consumption. My impression of Lambda was concerning, it integrates well with the other Amazon services SQS, SNS, S3 , I considered the potential vendor lock-in #7. Again, I went to this talk expected a lot more beyond event-driven architectures.
which is a framework to define cloud Infrastructure-as-Code and provision it through Cloud Formation.
I wonder again why a DevOps and/or Platform engineer would choose to build their infrastructure with a language such as Java against the CDK? A lot of the industry already relies on Terraform or Ansible to provisioning.
The Well-Architecture Booth
In the exhibition area, at the AWS Summit, I went to the Well-Architected area where you book a question with a certified AWS solution architect. I did not have a question, but I joined a couple of folk who had questions on security, migration data to the cloud and another on EKS. This area was partitioned into several services from serverless to machine-learning and you had to queue and register to ask a question, I realised at the same time as the EKS guy, and he left to go out of the area to the AWS certification training booth. He had to register first there before he could come back. Perhaps I misheard, it was weird.
I lurked with the others folk and listen to security advice. How do break up the AWS user profile into separate functions, responsibility in my big DevOps team? The advice was pretty sound, devise lots of IAM roles and be extremely care of a Read-Only
role that includes S3 read-write access globally! Instead, customise this role and remove the S3 vulnerability part of it. Prefer to compose new separate IAM roles together. If a DevOps is only allowed to manage S3 then devise a IAM role for this Amazon service, and combine with staging roles e.g. Prod
, Dev
, UAT
and then combine it with business specific area roles OTC_DevOps
, Forex_DevOps
and Risk_DevOps
. Essentially, you want only one or two people to have Administration Everywhere. Sound advice.
I also had a listened in politely to pair system integrators asking a data ingestion into serverless for machine learning. Their warehouse was in a company third-party data centre and they wanted to migrate much of it into the AWS data store for Lambda processing. Fascinating stuff and some ideas.
Finally, I bumped into an Amazon staff solution architect on a break. He told me how this area worked. Attendees could book each session, in advance, with a solution architect to ask a single question is up to 15 minutes long. They used a countdown digital timer and a remote control to switch the booth light from green (free) to red (occupied/busy). This fellow found his solution architect job at Amazon, by first, doing the training course at his old company, where he worked as an infrastructure engineer looking after data centres. His company was in the middle of migrating data to AWS and he found common interest and a reason to study up for the exams. He took them and passed them. One day, he saw the AWS job advert online and applied directly to Amazon UK. Very cool for him.
What did I want to leave the event knowing more about?
I wanted to still learn more AWS Lambdas and event-driven architectures. It was my own failings for not entirely pursuing this learning path. I believe this architecture type is part of my overall learning of cloud-native architectures. Lambdas represents system where you the customer are happy for the provider to orchestrate your services and function at scale. On the other side of the spectrum, which I am more familiar with, customers and clients definitely want full control the EC2 instances, VPC, ELB, F5 and other AWS services. This is the IaaS side. I believe I am moving into solution architecture.
I went around the exhibition area and I spoke to several companies. I grabbed a rustic bag from VEEAM N2WS. I went to New Relic and talked to a guy about their solution. SaaS logging and data analysis is an interesting idea for people and customers. I can see the concerns about data privacy and trust in data at rest. I spoke to the Data Dog people, who were pretty fun. They have a lot of over 200 type integrations into much open source libraries and of course AWS. I talked to somebody on the Mongo DB stand. I blethered with Nutanix on their solutions to transform architecture at the edge at scale. I spoke to Frame about their secure private cloud platform offering. Sadly, there was ONE MISSING COMPANY #8 that I wish did attend AWS Summit London 2019!
Hashicorp is the company behind Terraform, Vault and Consul.
Perhaps, because this company is agnostic to the cloud platform, is a reason they stayed away. I understand that they doubled their number of employees between 2018 to 2019.
Conclusion
The Well-Architect booth area was for me where the action was really happening. Yes, I was eavesdropping and lurking about and I should have stayed there all day talking with the certified solution architects. On the other hand, there were at least two interesting sessions to go to. Blast it! Time travel has not been invented.
For a one day FREE conference AWS Summit London takes some beating. The gentleman’s but, however, it is not a user networking event. You will not find AWS user groups or an Amazon community outreach team hanging out in a separate designated area in the conference. You are in Jeff Bezos’s house and you have to take the marketing and accept it. If you were looking a full time job, this was not the event for you, with 6000 strangers, forget it. I did not see one iota of a physical job board where you could stick your business card like you can do at a Skillsmatter event. It’s not the unconference that you are looking for. People are unknown to each other for a one day event, hallway conversations are minimal. There were plenty of blokes and some women. It took place in London though, cosmopolitan and multicultural, so this event was diverse, racially, gender mixed, attended by all cultures. Agewise there were many a CTO and Director of engineering whatever, Head of Trading forget-about-it, the people of grey hairs like myself, walking around in smart-casual shirt and slacks rubbing along with the tee-shirt and rucksack brigade, and, of course, being a London event, plenty of folk hopped across the English channel and the North Sea to be there. Thank you Jeff for this event. I will definitely go next year AWS Summit London 2020.
+PP+
May 2019