24 thoughts on “Traditional vs Cloud Native Applications

  1. I think, from most of the coments in this video we can see how this is such a nice "breath of fresh air"… Sometimes, especially in the topic of software development it's almost Impossible to find good explanations to a concept and not just a crappy, generic, almost advertising-like vídeo… Like that IBM vídeo wich is a bunch of bullshit talk about how everyone should be using cloud native architecture and never getting to the point of why and what it is… We love straight to the point explanations and documentation, and not stupid waste of time videos and adverstisement as I see a lot in the software engineering community nowadays. Thank you sir!

  2. Tony – great video. How would you migrate a multi tenant database to AWS that has 100's of individual customer(cannot get outage windows for all of them at the same time).

  3. The explanation given for traditional environment tend to miss the session replication feature which was implemented in clusters.

  4. Agree with the second part talking about elasticity, however, the first part regarding stateless, or non-sticky apps is not that clear and obvious IMO. Micro-service + K8s is the core of cloud-native.

  5. Useful video but the first part (shared storage for traditional apps), didn't really make it that convincing, since stateful applications do not have to store their data locally – why can't they store the user status (logged in, items in shopping cart) on a shared SAN? The second part (scaling out vs scaling up) is more convincing. Are there no other compelling reasons, aside from being non-sticky, for Cloud Native architecture?

  6. Cloud native apps is a form or evolution that can be to a PaaS and IaaS app? or how is the relation with the cloud models ( paas,saas, iaas) ?

  7. Good explanations, but.. your 'pets' explanation doesnt cover clustering of the a server ie multiple prod servers synchronized to fail over to a contingency environment that is in warm stand by… so that 'cart' persistent data would actually exist in the failed over server you mention.

  8. Good Explanation. But the last point, when you explain that scaling up and down is no problem anymore, dont shows me that the benefit of Loadbalancing remains. Here in the newer approach all servers get all the requetsts/data.

  9. removing stickiness to support elastic load balancing seems logical but it leads to problem of not being able to execute actions on given shopping cart / any entity in sequence since multiple user actions on same cart could go to different server. This could be very important in many cases. Also, any attempt to synchronise access to shared data impacts performance severely. In my experience of trying to solve this in recent years, middle ground is to keep stickiness for old requests ( short life span ) but route new requests across all servers.

  10. Tony, your Shopping cart analogy is poor. How do you manage database lock on rows that you have just read for update in cloud computing if you run the same transactions on multiple application / web server? Your explanation is good though but and Cloud based transactional application is good only if you are reading the data objects from cloud storage or block storage (SAN), not for update / database commit. Your approach is not the solution for all business scenarios. If you follow CAP theory of database, you can only achieve eventual consistency in cloud, and if you need strict consistency on the data in the cloud native application, you must maintain or enable stateful. What I expect from the system is that, once I put an item in shopping cart, it should be available until timeout or complete my transaction. Thanks.

  11. in tradition apps , we have in-memory session replication option in middleware servers to replicate sessions among other servers so that the session wont be lost when a server is down and also if required we can disable sticky session at LB level.

  12. That was a really nice explanation. Can you kindly give a demo of how to refactor a traditional application to make it Cloud Native? Thanks in advance

  13. maybe I missed an explanation: why in cloud apps the load is immediately shared when adding VMs? Is it that all VMs share the state, but only one of them is processing the traffic at any given time?

Leave a Reply

Your email address will not be published. Required fields are marked *