[Summit] AWS Summit Review

I attended the AWS Summit on May 17, 2024.

AWS Summit Impressions

Purpose: to see what products various companies were bringing out, and to get a sense of market trends. (I'd promised some former-workplace colleagues we'd go together.)

Figure 1. AWS Summit badge (name erased)

The AWS Summit badge looked really premium. There seems to be something like a magnetic ID-recognition chip inside. Every time I visited a booth, it was scanned not by a barcode but by something magnetic inside it. (I erased the name cleanly with an eraser ^^)

I attended AWS Summit with former-workplace colleagues. To give my overall impression first: I came away thinking that all software product ideas just go around in circles. Only the level of implementation differs — there were many solutions and products applying nearly the same tech stacks for nearly the same purposes.

But what I felt here is that, although I said only "the level" differs, that level itself seems to become the competitive edge.

As a basis for "level," I think you can split it into two: 1) the UI/UX side, 2) the performance side.

1) The UI/UX side

If a product has a UI/UX that's hard for users to use, then no matter how good the performance is, people won't use it. (Unless it's a truly unrivaled product, if there's even one alternative, people move there.)

• Personally, I believe UI/UX must be intuitive, no exceptions. This is exactly why you need a planner with a lot of UX experience.

2) The performance side

This, I think, ultimately comes down to a company's core technology. Even if you make a feature work, if processing time gets longer as data accumulates, or if exporting a single file takes more than 30 seconds (it varies by domain), then people stop using the product.

I've even seen a company that — because an ordinary database couldn't handle the case — captured packets at layers 2–3 to do the work. (Not at this summit, but at another SKYST conference.)

The products on display

Now, setting aside my impressions of the summit, let me look at what products were on display.

Figure 2. The AWS photo zone at the venue

Samsung SDS, LG CNS, SK Inc. C&C, GS Neotek, KT DS, Hyundai IT&E, MongoDB, Nginx, PagerDuty, Datadog, and many other companies took part in the summit and exhibited their own solution products. The representative product categories here could be classified mainly as CMP (cloud management platform), AI (LLM) serving services, and middleware (API Gateway, Web Server).

Figure 3. List of participating companies

1. AI serving services

The principle of AI is, mathematically, curve fitting, but the way it's applied and the way it's trained differ by domain. Accordingly there are various domains — computer vision, natural language, time-series forecasting, generative AI, and so on. Among these, the especially hot one is generative AI. Products in this category included chatbots, email services, personalized assistants, and image generators.

One thing I enjoyed experiencing was the "past-life experience" photo that AWS provided directly. You take a photo in front of it, and it generates your photo in the feel of whatever your past life was. And a description even appeared below it.

Figure 4. Past-life experience (generative AI)

It was a generative-AI past-life experience service — the kind of thing you'd expect to find at an amusement park. :)

2. CMP (Cloud Management Platform)

More and more companies are transforming into MSPs (Management Service Providers) and offering CMP. CMP is essentially a platform that helps you more easily use the cloud services provided by CSPs (AWS, Azure, Google Cloud, etc.). A representative example was a service that helps you use multi-cloud easily.

The concept of Multi-Cloud

The concept of multi-cloud is to pick only the services you need from the various CSPs (AWS, Azure, GCP, etc.) and compose your own public cloud network with them. Here you might wonder: why mix them? Isn't the concept of composing a virtual network something every CSP already has?

This can be justified by reasons related to policy. For example, there can be policies like: if you build an app using a certain GCP service, the Play Store discounts its commission. Accordingly, you could use GCP for the Android app and AWS for the rest, composing your network to optimize on the cost side. As a result, considering your service's price, performance, and so on, you can pick only the favorable policies and compose a single cloud.

A company that builds and provides a platform helping with the above composition is called an MSP. Representative ones include Megazone Cloud and SK Inc. C&C, and recently various companies such as KT DS have started this business. For reference, CMP usually provides not only multi-cloud-related services but also network-related monitoring/operations.

What I felt about this: with interest in the cloud growing recently, it's becoming visible that many companies are paying attention to CMP and jumping into the business. Personally, since I think AWS created the Cloud Native paradigm, if you already have some networking knowledge, learning the Cloud Native system with AWS as your baseline looks like a good idea.

3. Middleware

Traditionally, middleware plays various roles — data buffering between applications, authentication/authorization, routing, load balancing, and so on — securing stability through load distribution and security between applications.

A representative example is Nginx, which serves as both a web server and a reverse proxy server. And the API Gateway — which, between client requests and service communication, holds authentication/authorization and a rate-limit feature via the token-bucket algorithm — can also be an example.

Nginx is so famous that I don't think it needs separate mention. I plan to post about Nginx installation and configuration later as well. As for the API Gateway, KT DS makes and provides one as a solution called Vesta. It had everything from the monitoring domain to features for tracing the logs of multiple APIs.

The concept of an API Gateway

An API Gateway mediates so that communication between services is stabilized and failures don't occur.

1. Basically it does routing. It forwards client requests to the target service.
2. Even at the moment a burst of requests occurs, it limits requests via rate limiting, easing the load on the service.
3. If one of the several services going through the API Gateway fails, a Circuit Breaker temporarily cuts the connection so that the failed service doesn't affect the others.
4. When a client sends a request, it checks whether the requesting client is an authorized user — authentication/authorization.

For middleware in particular, performance seems to matter most. Since it's the gateway for communication between applications, if performance is poor it can actually become the bottleneck. For this reason, I think it's hard to turn into a solution unless you sharpen your core technology, or really master an open source like Spring Cloud in depth.

That's the impression I leave after attending AWS Summit.

I think going around to each company's conferences and summits — seeing and feeling the trends — gives inspiration both business-wise and development-wise. Since my own thinking isn't the only right answer, it feels like a really good opportunity to share what other companies are thinking, or what individuals at other companies are thinking. :)

📦 Migrated from the Tistory blog I used to run. Original: taehyuklee.tistory.com/11