Cloud infrastructure decisions are too often based on personal taste and experience, and that makes a problem. What is good for large, mature systems is too expensive and complex for early stages, while early stage shortcuts will block system growth one day. In addition, cloud vendors release new features constantly, making custom solutions obsolete or risky and previous assumptions not valid anymore. And that's a real problem that doesn't have Magic solution and my presentation will look what practically could be done about this. Welcome to cloud native 2025. My name is Asher Sterkin. I have about 40 years experience. Previously, I served at different senior engineering positions and large multinationals. And today I'm mostly focused on advanced cloud architecture solutions. Both details could be found on my social networks. Let's look what is included in making decision about cloud infrastructure. What we need to decide about trust. We need to decide about cloud, what cloud to use. It could be WS, Azure, GCP, smaller player like CloudFlare. Some people believe that Kubernetes is a real cloud, while what we call cloud, actually hardware. The Kubernetes true cloud is running on the top of a kind of philosophical debate. What is right? What is wrong? Once we decided about cloud platform, let's say AWS, there are a lot of choices to be made. What compute platform we need? Virtual machine, serverless lambda function, container based solutions like Kubernetes or ECS, maybe more exotic options like step functions. How we store data. Which kind of database we need. Relational, non relational, blob storage. What kind of internal communication we need. Peer to peer message queues, PubSub infrastructure, streaming. What kind of external interfaces we expose. Just load balancer or API gateway or maybe GraphQL supporting AppSync. We need to make decisions about system observability. How log files are produced. How metrics are collected. How alerts are raised. How they are processed. How history is kept, for example, cloud, cloud watching Amazon and, Athena for query. We need to decide about automation infrastructure, how we deploy cloud resources. It could be cloud formation of Amazon, CDK, cloud, cloud development kit, more Kubernetes focused helm. more generic terraform or its open source, version or open tofu or more sophisticated orchestration platform like Lummi. There are decisions to be made about development environment, separating cloud solution architecture and software development Architectures wrong approach. Cloud SDKs are sup supportive for particular round time environments, be it Python, no GS, java t net, or. On the top of them, there are multiple programming languages, and all this combination will determine how much CLI we will need from the cloud. Very seldom we could come up with one clear cut choice here. How we make decisions, or let's say, how we are supposed or expected to make decisions. We are expected to make decisions fact based, as a kind of rational process. What workload of the system we expect, what server level, service level agreements we need to support in terms of latency and throughput, what security requirements are, what cost constraints are, what time to market we need to address tomorrow or one year from now, and what brownfield constraints we need to deal with because very seldom we deploy completely clean slate solution. In reality, decisions are made not this way, as I mentioned in my introduction. It's based on faith, what we believe is right or wrong, or a certain kind of bias towards a particular choice. Experience, if something worked for me in my previous project, I will most likely push towards this option for the next one, whether relevant or not. There are certain likes or dislikes and fashion hype. And one extremely dangerous is so called trust. High, tight person, opinion. Senior manager who believes, who know he knows or she knows what's right or wrong. Very often based on who he's playing work with. A more effective approach to that challenge would be set based engineering. At the beginning, we know very little about. Many aspects of the system, what external interfaces exactly we will need to deal with, how much load we will have, maybe security changes will change, or even target market will change. So we need to evaluate the number of candidates and keep as many options open as possible. Eventually we will converge to smaller number of configurations. Very often, usually reflecting different environments we need to operate in, like developments, test stage production. One configuration will be locked for production. However, based on feedback and metrics collected, we will most likely need to come back to stage one and evaluate new candidates or re evaluate previous candidates and start this whole process over. This presentation is titled Focus on Core Value and Keep Up. Cloud infrastructure flexible with ports and adapters is a architectural pattern, sometimes called hexagonal architecture that allows to separate infrastructure and application to keep them separate and Prevent the influence of infrastructure on core value. This pattern was introduced by Alistair Cockburn and published in this seminal book. Very highly recommended. The pattern contains several parts. The first one, we isolate application completely from infrastructure. The application logic doesn't know anything about what infrastructure it will run on top of. This is achieved through well defined ports. in ports or out ports for system inputs or outputs, ports are slightly more than interfaces. It's a collection of interfaces with the same technological choice and data that flows through them. Every port might have multiple adapters implemented on top of different infrastructure, and adapters are plugged into system through ports by configurator. Configurator could be static or on. In the book, they use a sample application called BlueZone, which is actually a parking lot where drivers buy tickets and inspectors check whether cars are parked valid or not. We will use this application in our conversation. The process is supposed to start with use case analysis, answering the very simple question why the system exists, what kind of value it delivers to its users. In our case, we have two use cases in this application. One is buy ticket for car initiated by car driver and communicating with payment service, credit card maybe. The second one is checking card initiated by parking inspector. Use case actors provide strong input for what kind of primary ports the system needs. Primary driving ports are for actors initiating use case. In this case, for Car driver and parking inspector and, primary driven ports for external services we need to use, consume, like payment service. So we have primary, primary ports derived from use case specification. Use case event flow specification will provide an input. for secondary ports. If we need to store some data somewhere, we need a database, so we need to define a secondary port for database and not lock ourselves into a corner with a particular database choice. On the other hand, in this particular application, we need to know what the current time is to put it on the ticket and check whether the ticket is expired or not. So we have secondary driven ports. Actor interfaces, more detailed technical specification of how we are supposed to communicate with actors will most likely determine which protocols we need, be it REST API, GraphQL, or maybe open system to system integration through MQP protocol. Use case SLAs in terms of throughput and latency plus data schema stability will define what kind of database, what type of database is most suitable for that. If you have a stable, relatively stable schema and need a lot of flexibility for ad hoc queries, a relational database like Postgres will most likely be the best choice. However, if we have a very flexible schema, a document database like MongoDB might be a better option. And if we have very high throughput, low latency requirements of the system, columnar based, non SQL database like Cassandra might be better choice. Cloud platform itself is very often determined by so called supplementary specification. Customers specify what they need. Regulators tell us what clouds we could use. Legacy systems to integrate with will determine which cloud we can use. And so that comes from a supplementary specification. Once we have cloud decided upon, time to market considerations will push towards adopting native serverless options from that cloud platform. For example, Lambda and API gateway for compute or Lambda and AppSync for GraphQL based interface or MQ service for MQB. Serverless Aurora for Postgres, Serverless DocumentDB for Mongo, Serverless Keyspace for Cassandra, and most likely CDK, Cloud Development Kit for orchestration and deployment. It's just much easier to put stuff together and deploy using that, this set of options than anything else. However, when we deploy to production, we start collecting metrics, we start getting feedback, and it might be the system is too expensive, or not performant enough, or there is a certain feature gap, and then we start considering alternatives. For example, NEON database as an alternative to Aurora for Postgres, or Atlas database for Mongo, or Datasex Cassandra for Cassandra. We may discover that we have stable load, high load. And Lambda is not a good choice anymore. And switch to Kubernetes behind load balancer. And that will determine what kind of automation we need. Maybe Helm. And maybe we need, we have more sophisticated needs for deployment operation and switch to Pulumi. The book suggests certain canonical structure for application to reflect that pattern. Keeping application logic. Adapters and ports in separate folders, in separate packages. It's a very high level structure. Details depend on which domain we are developing software for, what programming language we use. What business model we have, whether it's software as a service or cloud independent software vendor and what is core technology, whether it's infrastructure or application services like e commerce versus, let's say, cyber security. To sum up, Ports and Adapters architectural pattern is really very powerful tool to deal with uncertainty and flexibility in complex software systems. Very often we don't know enough at the beginning and we will need to make our choices later. Almost for sure. This is just the beginning. What I presented here is just the tip of the iceberg. If you are interested in more details and more detailed discussion, drop me a line. Here are my details on, social networks. Thank you for your time and attention and hope to see you again.