stackconf 2024 | On-Prem is the new Black by AJ Jester
•
1 like•28 views
In a world where Cloud gives us the ease and flexibility to deploy and scale your apps we often overlook security and control. The fact that resources in the cloud are still shared, the hardware is shared, the network is shared, there is not much insight into the infrastructure unless the logs are exposed by the cloud provider. Even an air gap environment in the cloud is truly not air gapped, it’s a pseudo-private network. Moreover, the general trend in the industry is shifting towards cloud repatriation, it’s a fancy term for bringing your apps and services from cloud back to on-prem, like old school how things were run before the cloud was even a thing. This shift has caused what I call a knowledge gap where engineers are only familiar with interacting with infrastructure via APIs but not the hardware or networks their application runs on. In this talk I aim to demystify on-prem environments and more importantly show engineers how easy and smooth it is to repatriate data from cloud to an on-prem air gap environment.
Report
Share
More Related Content
Similar to stackconf 2024 | On-Prem is the new Black by AJ Jester
Similar to stackconf 2024 | On-Prem is the new Black by AJ Jester (20)
Recently uploaded
Recently uploaded (20)
stackconf 2024 | On-Prem is the new Black by AJ Jester
- 1. 1 On-Prem is the New Black Why has reverse cloud migration been the cool thing these days? 1 Prepared by: AJ
- 2. 2 2 Cloud computing was meant to cut costs, right? ● Beneath the surface of straightforward subscription fees, a complex web of hidden costs lurks. From data transfer fees to compliance costs, and the often-overlooked expense of cloud sprawl - the unchecked proliferation of cloud services without proper management. ● We need to factor in the cost of moving data between services, the expense of additional security measures and the premium for scalable services that you might not always need?
- 3. 3 3 Knowing is the first step to Optimizing
- 4. 4 4 Cost of Cloud ● When running a startup that is new with a few hundreds of users, cloud could be cost effective. Which is okay for a small app. ● As the the app grows popularity the user count increases to say a couple thousand, the cloud bill increases exponentially as the same operations as happening. ● The data is increasing but the patterns are predictable and similar. ● Difficult to control the costs even with all the billing tools available.
- 5. 5 5 Leaving the Faucet running
- 6. 6 6 When could Cloud be used? ● Large Enterprises that might have a diverse need doing a vast array of things. ● Small enterprises who need to quickly bootstrap for a seed round with a few hundred users. ● For quickly reconfiguring ecosystems as the needs change rapidly. ● For use cases that are unpredictable and need to adapt. ● Ultimately its use case specific.
- 7. 7 7 The Billionaire Yacht Club
- 8. 8 8 Moving to Cloud ● The companies go over budget trying to optimize the cloud. ● Cloud bills will go out of control because the apps were not optimized for cloud tools. ● Optimizing Applications running on prem into cloud. ● Cloud bills could also go out of control when you do not manage resources and let them run for extended periods.
- 9. 9 9 No optimization while Moving to Cloud Metrics Logs Applications Databases Migration to Cloud OnPrem Applications Applications on Cloud ● No optimization of the existing application to modernize it. ● App needs to be refactored to use the cloud more efficiently. Metrics Logs Applications Databases
- 10. 10 10 AI ML Workloads ● GPU Processing is very expensive in the cloud. They are GPU and Storage hungry (from the data they generate and store). ● Having your own hardware on-prem with GPUs is much cheaper. ● You have more control over your models. ● Have a fast backend storage for your models to be stored and quickly be accessible by any application at any scale.
- 11. 11 11 For AI/ML workloads use high performance, Kubernetes-native, resources that are designed for large-scale data infrastructure. The tools must be cloud native, as a result, things are standardized for the hybrid cloud & multi-cloud. TENANT 1 TENANT 2 TENANT n Object Storage CPU NETWORK DRIVE APPLICATIONS AI ML Workloads
- 12. 12 12 Repatriation Challenges ● Lack of OnPrem hardware and systems knowledge. ● Initial hardware costs ● Ease of cloud native tools, or lack thereof. ● Harmoniously working with Cloud services in a Hybrid environment ● Reverse Migration: Moving services back to OnPrem that should never been in cloud in the first place. ● Some Cloud advocates have taken things personally and would not hear or see any alternative narratives.
- 13. 13 13 Cloud is an Operating Model Not a Location Multicloud Hybrid Cloud Kubernetes Distros + the Edge AWS, Azure, Google, Oracle, IBM. On-prem (private cloud) and the public cloud. Colocation On-Prem. OpenShift and Tanzu lead - but Ezmeral, Rancher/SUSE and there are others.
- 14. 14 14 CI/CD Concepts ● Artifact ● Artifact Repository ● Continuous Integration ● Continuous Delivery ● Pipelines ● SLA Inversion ● Infrastructure as Code ● Provisioners ● Twelve-Factor App
- 16. 16 16 CI/CD Bake N’ Fry ● Baking is an artifact purpose-built for a specific application. ● Frying is a generic artifact that could be used across many applications.
- 18. 18 18 Cloud native tools ● Packer: Image building ● Vagrant: Infrastructure testing ● Service Discovery and KV Store: etcD, Consul ● Vault: Secret Storage ● Artifact Repositories: Docker Hub, Jfrog Artifactory, Harbor, Quay, etc. ● Storage: PureStorage, MinIO, Cloudian, anything S3 compatible. ● Infrastructure as Code: Terraform, Puppet, Chef. ● CI/CD: GitHub Actions, Jenkins, Spinnaker.
- 19. 19 19 Cattle vs Unicorn Resources should be treated and designed more for cattle than unicorns. If we want to start treating resources like cattle the name should give just enough info so you know where your services are running but at the same time as random as possible so there are no conflicts. The advantage of doing this is you avoid having snowflakes that are unique and that makes automation difficult because there is no pattern.
- 20. 20 20 Airgap ● When deploying an application, any application, we need to consider the type and whether it needs to be in a particular portion of the network. ● If you are deploying a database, you do not want it to be on the Public network, you probably want it to be in a Private network where it cannot be accessed from the outside internet. ● An airgapped network, as the name suggests not only can you not access it from the internet, but you cannot connect from the node to the internet either. The nodes are completely locked down in this network. You might still be able to access them via VPN but generally it's recommended to connect to a bastion host and then have the airgap network accessible only from the bastion node’s private IP.
- 21. 21 21 Airgap Use WAN Link between geographically dispersed sites
- 22. 22 22 Open and Honest 3 Broad Categories: ● OnPrem Hardware Knowledge ● Thinking of cloud as an operating model ● Using Cloud native rules across hybrid environments 3 Broad Categories of Engineers: ● Data Center Engineers ● DevOps / SRE Engineers ● Application Developers / Software Engineers
- 23. 23 23 Is this the Curtain call?