Saudi 2022. My name is Handoyo Sutanto. I am the CEO of Lyrid. I'm so excited to be here today as this is my first time speaking at Cloud native and let me tell you a little bit about my self I'm a software engineer solution platform engineer by true father of two and prior to starting Lyrid I was a director of platform engineering. I have spent more than 15 years building cloud solution from the ground up. I build everything from a data center infrastructure to a globally available applications and web services and two years ago I started lit as an idea on how to seamlessly integrate and deploy cloud infrastructure using cloud agnostic technology while breaking any reliance on any one cloud vendor. So in this talk we will walk you through on what it takes to build a scalable solution, applications or web services that utilizes cloud agnostic design principle, the four keys engineering decisions that we took to make it happen and what is the outcome for us. And by the end of this talk you will learn about the pros and cons of going cloud agnostic and have more actionable tips on how to implement cloud agnostic in your organization. If you learn anything interesting, please tag me at hondus Twitter and use the Con 42 hashtag. Let's start with what does it mean to be cloud agnostic? By its most basic definition, a cloud computing is the delivery of services such as compute, databases and networking over the Internet, offering faster delivery and innovation to vendors like Google Cloud, Microsoft Azure and Amazon Web Services. But what does it mean to be cloud agnostic? By definition, cloud agnostic is a strategic process of using two or more public cloud for your workload. Generally, before going cloud agnostic, companies are restricted to one cloud vendor during their app development and challenge with keeping the operational costs low while maintaining scalability and availability. While there are many reasons cloud agnostic can be great for your business, youll first want to determine your specific business needs. Let's walk through its benefit. The first one we want to mention is that cloud agnostic creates freedom. With Cloudagnostic, you're in control of all your tools, making, tailoring and feature pairing seamless for all your business needs. At Lyrid, our tooling enables the deployment of user solutions in any cloud environment. Depending on the business needs of our partners, we give our users the freedom to access the tools and the features they need whenever they please. Now, the second benefit that we want to mention, cloudagnostic provides you with choices as region, offering prices and all important factors when it comes to choosing cloud providers. Implementing cloud agnostic mindset. Youll will be able to make informed executions on these factors and many, many more. It grants flexibility to meet all your needs, whether it's financial, functional or performance based. Having multiple providers to depend on is critical in such a changing it environment. This flexibility is also apparent in solutions portability and streamlining migration process. The third one we want to mention is that it lets you scale when it's needed. Contrary to common belief, this type of platform making scaling so much easier, especially for complex enterprise applications. Youll infrastructure scales with your solution without the need to configure or write a new code. We've been doing this and we've been helping our partners leverage Kubernetes auto scaling solutions with some benefits of this including automatic application management, a decrease in engineering maintenance and significant executions in overall costs. Fourth one, it provides long term savings. Cloudagnostic strategy lets you lower long term costs without forfeiting data efficiency. The flexibility of savings multiple cloud platform under your belt allows you to switch providers or even see service with a provider if a better deal comes along. Now let's take a deeper dive into what are key decisions when it comes to going cloud agnostic development. And before you start coding a single line of code, the first point is that youll technology stack matters. Pick the right technologies and as an engineer, your goal is to deliver a timely solution to the stakeholder within budgets. Consider your executions, compute, storage, database and network as the lifeblood of your application infrastructure. Make sure you know what you're putting into your lifeblood and choose the one that are not restricted to your application. One of the biggest value proposition that cloud company have is the ability to create any infrastructure with extremely low costs that bypass the barrier of entry. However, some of these services implement technology stack that does not exist on any other cloud platform. A good example of this is database that only run on certain cloud vendors. These services provide the most seamless integration to their services. However, they also have the least migrable database services to other cloud providers. So I like to start small with bring your own distributed database and then extend. Choosing this technology doesn't mean that you'll compromise in scale in the future. So we pick technologies that can expand seamlessly with no downtime and some of these open source technology with high availability and redundancy options are the way to go here. And there are many technologies that is built on top of that and that can ensure that your data can also be distributed across many cloud platforms. Once you start putting your solutions together, you'll want to make sure you start with abstraction on libraries that you think youll need to be migrated or run on multiple platform. So my next point will be use abstraction library as much as possible. An abstraction pattern library is a code that is common in solution development that allows developers to interact with a system using a more generic interface and one example of this is using object relational mapping or ORM. ORM itself is a programming technique for converting data between type system using object oriented programming language. Some of the example if you use Prisma for node JS, SQL alchemy for Python or entity framework for. Net you have used these types of abstraction and at layerit we use ORM and other abstraction databases layer for our messaging use system as well. For our job distribution for Google, pubsub, AWSQ, SWS, SQS and Redis we have been able to convert between cloud services for some of our service that requires a more global distribution and on premise deployment in an instant. So once you have built a concept and have a running application, what do you have to do next and for the next key decisions that we actually have to build is we would like you to embrace the distributed architectures and design for replaceable and migratable microservices. For cloud solution deployment, we recommend utilizing distributed computing because it embraces redundancy as well as high availability. Modern development has always advocated for smaller component that can be easily run on any system with a distributed storage system continuously making data copies, allowing a great deal of flexibility around costs, time to recovery, durability and more. They are extremely tolerant to compared failures. Outright distributed architectures have become more standardized in the developer world with the help of a massive cloud adoption, along with the wide adoption of technologies like docker containers during development? Ask yourself these questions. Can this same code or API run on another cloud platform? If not, why is that? What do you have to do to mitigate before you're going to production? And for the last keys engineering decision that we made to be a cloud agnostic company is to build and keep up with your migration plan. At this point you have all your solutions in place and are probably only using one deployment region and cloud services for your application. So the next thing is to come up with your plan b, a high level option to adopt a cloud migration strategy with one or more cloud vendors in order to quicken workload and data migration to another cloud. However, this option can be costly at first and may not be critical to running your business executions initially. But if you build your solution using the first predecisions above, we can always start small and design a manageable plan and identify important pieces that can be easily migrated. As you're running your solution, pick a target cloud vendor or technology to migrate to and test and run youll migration once a month or so. We like to put ourselves as a case study on a company that implements all those four key decisions. We would like to show our current technology stack infrastructures and with this we were able to automate, design, control and distribute our platform to multiple cloud vendor. As we mentioned earlier in the talk, we chose Kubernetes as the base of our platform. Kubernetes is an open source container orchestration system for automating, software deployment, scaling and management and for storage and data. MongoDB and Minio are our go to internal database and storage. They both are excellent open source technology that can provide the flexibility to be distributed anywhere along with redundancy and availability and backups that are required for us to run our operations. For database redundancy we rely on building MongoDB container instance inside all the Kubernetes cluster that we maintain. This is to build a globally distributed read only cache. This proved to be very benefits for our end users experience and something that is crucial for us is the ability to distribute our jobs and build and deployment globally. This scenario we use Google Pubsub as one of our job distribution infrastructure, but internally we can easily switch between Google Pubsub to a self hosted redis pub sub for our development. These are the base of our infrastructure that runs our platform and with this we have created a distributed deployment engine along with an API layer that connects with outside services to create a public cloud compute abstraction. So we made our platform with a goal so that it's easier for anyone to build using these same four principle. So let us show you how you can accomplish this in a quick demo of our platform. In this demo I will show how alert uses these four keys and where they show up in our platform. Our platform is free for everyone to try what I'm doing here, so just sign up and log into it and let's deploy alert pre made cloud agnostic application. The technology on what you pick here matters and these are some of the example of application that we have published the template on GitHub to help accelerate your development. Feel free to check back in the future for more pre built templates, but for today I will deploy a next JS application into our platform and what this does is that it will create a clone of our pure next JS code that does not contain any cloud library or signature. So let's click deploy here and what happened in the background here is that the template is copied into our minio backend object storage and we start to distribute the build jobs across our cluster. I think youll pretty familiar with some of these logs that these are built container build jobs on our distributed docker container engines that lives inside our cluster. The distribution of the jobs is handled by Google Pubsub, but it's also working on Redis pubsub for our clients that requires more security in their environment. Now once the build is complete, our platform will start the distribution of the code to the public cloud vendor that we support. This is where our platform does the heavy lifting of creating and configuring the appropriate public cloud services. Without the need for you to know a lot about AWS, Google Cloud or even Kubernetes. We create our cloud specific deployments and abstract approximates to you so that you only need to focus on what's important to you, which is your application. And when this is done we provide you with alert API endpoint and this is a publicly available HTTP endpoint that is running an API gateway into the execution of all the deployed application services. Let's open it and check our splash page if it's working. And by default this only runs in our layered cloud platform. I will show how to set a policy to this endpoint so that it utilizes other clouds. But let's download the code to take a deeper dive into the next JS code. And I extracted and opened the folder in visual studio code and you can already see the structure of the code right here. Other than our definition file, we are not requiring you to download any packages that are cloud specific. The package JSON file shows that this is a pure next JS application and the only file that's required for us is our alert definition file that tells the platform on how to build and pack the services. Now if you know a little bit about next JS, the code structure is pretty standard with styles public and pages folder. And in this code we added an API endpoint that can show the current next JS node JS version as well as the unique environment of Lyrid that can return which cloud environment that is currently running on. Now let's get back into our UI to set the policy and for deployment and execution. But before that we need you to set the credential that will be used under youll cloud account. This is an IAM role to be configured in your cloud account and our documentation provides a list of permission that you will need to set in order to interact with alert platform. Now we can set the executions platform to all in which it will run the service on any cloud and this policy to create a distributed application on all public cloud vendors. In this page you can also set different regions for Google and AWS. This will be the region used to deploy the first service in that cloud and the closer it is to the bulk of youll user, the better your user experience will be. Let's jump back into the web browser and check the endpoint and let's execute the version. Get endpoint and zoom a bit here. As I refresh really fast you can see that it is load balancing between AWS, Google and our own Kubernetes cluster. Congratulations, you have successfully created a migrable and distributed application. Now let's do a quick check what we deploy on AWS by going to your AWS lambda page. And now let's check on the monitors and let's do the same thing over in Google Cloud. Now keep that in mind that everything you see running in our platform is also running inside our Kubernetes platform that we maintain and we are working on the ability to connect also to your own clusters. There are additional things that you have to put into consideration when you're implementing a cloud agnostic solutions and the first being security and compliance. I often get asked how do youll make all these solutions secure? And one of the issues that often come up in multiple cloud environment is that you can no longer rely on one cloud security mechanism anymore. So in this scenario, zero trust security becomes a very important concept for us. This is a security model where you never trust and always verify. Devices should never be trust by default even if they are connected to a permission network such as corporate lan or previously verified certificate and HTTPs on everything is always a good first step to secure your communication between machines. We build and use multiple Kubernetes native servers that integrate with Cert manager. Let's encrypt to authenticate and verify communications between all our production machines and some implement other security measures such as active container scanning, hardening, role based authentication for the Kubernetes cluster that we maintain and many many more. The second consideration is the integration costs. Adding more deployment environment into the platform will cost us some more development time. Just remember, even if they are providing the same technologies, there are always little differences on how one cloud vendor delivers its solution. One example that we encountered here is our Kubernetes AWS deployment development. We noticed that the load balancer uses Kubernetes ingress services, uses public DNS instead of public ips. Monitoring is also a very cloud specific function that can be a bit challenging to create, specifically one that spans on any cloud infrastructures. And in order to overcome this we utilize Prometheus Grafana for our infrastructure metrics. Considering that runs within our internal environment ecosystem. During our platform development, we made sure every part of our infrastructure ecosystem is ready to be fed into our Prometheus infrastructure. Considering this is where we made our decision on where and how to automate our infrastructure expansion. All the data that is coming into our Prometheus platform and just like databases and storage executions, there are other infrastructure monitoring tools that spans multiple cloud vendors and able to run on any cloud infrastructure. Just like everything else in the world, nothing is perfect, not even cloud agnostic. Now cloud agnostic is seen by many as the future for cloud computing and while there are benefits, you should also consider these drawbacks. The first is being that it does increase complexity to your system and one disadvantage is that by gaining flexibility and features, your solution can become more complex and require more management. Portable solution and technology support come at the price of increasing complexity. Now keep that in mind. The second is that you have to consider is that there is a slightly higher upfront cost that youll may incur in your development. Now, while cloud agnostic does have the potential to save you money exponentially, in the future, you will face a slightly higher upfront cost. These come from various things like when you're not utilizing some of the feature of a certain platform, but you need the properties of the others. These can potentially add to the price, and data transfer costs can also become more expensive. With the cloud agnostic approach, sometimes you'll face unexpected data transfer which can be also confusing to predict. However, all these additional costs are manageable. If you set your budgeting accordingly and you have to quickening your development, you'll want to take the time to examine your organization's need to determine if a cloud agnostic approach is beneficial to your need. And in conclusion, there are many benefits to going cloud agnostic for youll company. But just like everything else, you have to tailor and evaluate the pros and cons specific to your company's need. And just let's recap the four key decision design principle that we ran to make our platform cloud agnostic. And they are number one, as picking technologies that you can control. Number two, we use abstraction libraries as much as possible. Number three, we embrace the distribution architectures and design for migrable microservices. Number four, we build and keep up our migration plans and we have followed these four key design principles to build our platform and we here at Lyrid use this platform to help companies to build their solution using the same cloud agnostic principles. So let us know if you have any question, concern or comments. We're hanging out at the discord channel. Feel free to say hi to us or email us. Email me at htanto at lyrid IO or drop me a message on my Twitter and LinkedIn. Thank you so much for watching my presentation and we hope you learn a thing or two about building cloud agnostic solutions.