I agree with statement that "Cloud Native systems are systems that benefit from cloud rather than run on it" however I can't agree that you need microservices to be cloud native. I designed and developed many monolith applications so called modular monoliths with clear boundaries between modules (subdomains) according to "12 factor app" principles and those apps use full capabilities of the cloud (continous deployment, running in containers, autoscaling, cost monitoring, backups, disaster recovery and so on).
Agree. The presentation is rather biased and because the speaker has had rather a low number of projects, the bias is visible. Someone with a dozen of clusters under their belt, both in the cloud and on bare metal, would present different facts.
Hmm... I agree that you need to make a way to "test in production" in the end - for those reasons. But I don't buy that it's bad to be able to run the entire stack locally. There are situations where you need it (often in debugging). That doesn't mean you do it always, but you should be able to at least spin up ad-hoc disposable dev-systems for parts of and the whole stack. ... also on you local system. ... which is also one reason, I prefer containers as the building block over FaaS.
I kind of don't agree. I have created clusters from scratch myself multiple times. Measurably, I could set up a cluster in 2 months, with various services and functionality for which Amazon probably needs years and multiple teams. It's way more fun, and you can fix things yourself much faster. As for the amount of learning: a lot. Lean software development also optimizes for learning, it's a core tenet. At the company where I'm at currently the CTO, we release 10 times per day, team of 4, onto our own cluster. The hardware is hosted somewhere else, and that company needs 2 hours to give us new machines. We don't have automatic scaling, but it would be easy to add. The whole cluster costs us 5 times less than any cloud provider and we have much better performance. We simulate the whole cluster with libvirtd, including a LB pair, 1 minute is spinning up the cluster. On Amazon, spinning up the same cluster needs 5 minutes. I could go an and on, but the advantages of doing your own are tremendous long-term.
Right on. I recently saw a comparison on running a RPi4 hardware for an entire year in AWS versus on premise. We're talking over 2k per year. Add a database along with a message broker and it may start hurting your wallet. Like microservice-based architecture, the cloud is not a silver bullet.
@@jimmyl9658 well, our cluster is not a toy, but I agree. Beside the money, you lose control, opportunity to learn, and performance. And no, it doesn't take a whole lot of time to create your own cluster on top of bare metal machines. For users of cloud: do you have IFs for development vs staging vs production environment? If yes, that's because you've lost control, you've given in to the cloud. Our other environments like testing are 1:1 identical to production.
I was thinking this too. For a fast startup with low technical expertise, full on PAAS is the way to go if you want results fast. But the slow, build it up approach is no doubt far more cheaper long term. And if you retain your expert technical staff, you have a bespoke system that isn't tied into vendor costs and services.
All the topics discussed from deployment to architecture to testing to team org still applies even for a "private cloud". I'd say cloud native is an approach and mentality rather than using AWS or not.
