What is small today may be large tomorrow. What you think as over engineering may be a future proof design. Just a thought 🙂

@@nishithonshorebackup7446 Develop your app faster. Find out sooner if it makes money. After that you can hire more people and change the architecture. But if you know its scale beforehand and choose microservice architecture then it's not future proofing.

A good example is stackoverflow, it's a monolith running on on-prem servers

@@nishithonshorebackup7446 or maybe it is just over engineering and premature optimization because your app may never get the attraction you wanted

@@nishithonshorebackup7446 future proofing is an anti pattern, you can not possibly foresee all future problems you will have with your codebase.

Sorry but Can you explain this a bit? “Building each function with we defined interface” - what it means? I couldn’t understand.

@@princezuko7073 if we use interfaces for each of the domains in the example like for cart, billing, users etc. It'll be easier to shift them to a microservice since each one is independently written.

@@princezuko7073 Interfaces can be used internally between the same system, vs only using them for external communications. Implementing them during initial design means that if you want to swap to microservices, the interfaces already exist and it makes it managable to migrate over (else you would likely be re-writing/refactoring basically the whole app).

@@benhook1013 And regardless, having well interfaced functions makes code easier to test using mocking libraries, rather than having highly coupled code which is impossible to properly test

@@saikrupacharyarendra850 thanks for explaining it @sai

I second that! Been through a couple of videos and this one is the most comprehensive one!

Welcome aboard!

What about when you move to serverless architectures where you pay for what you use and split your app into long running and short running functions? I ask because we’re doing a transformation and currently we deploy a monolithic app to a kubeneties cluster so we’re paying a constant fee to have resource’s running all the time, I would have thought moving this to lamda for all sub 10-15 minute tasks which is probably 80-90% of all tasks mean we pay fractions of a penny on an event and then any long running we move to step functions where we can or some docker container running on a smaller amount of fixed resources? Just wondering is all because I thought paying for fixed resources is more expensive than paying for time on resources?

@@buddinghero That depends on if you actually can use fewer resources to run the remaining 10-20% of services. If you still need the same number of machines of the same size to run those 10-20% of remaining tasks, then it'd be largely a waste of time to separate out lambda functions, and you now also suffer performance additional deployment pipeline overheads for no/little gain. Monoliths are typically quite efficient for resource usage (RAM, CPU, network bandwidth etc.) as you don't have additional overheads of separate running operating systems/process domains. A big downside of Monoliths primarily being you have to deploy the whole unit every time stuff changes and depending on the language the compile time might be a significant overhead too.

@@buddinghero If your services are used infrequently, serverless computing makes sense. But serverless is limited. Each cloud provider has their own serverless system so you are locked into a vendor. I normally use AWS. A request has to be processed within 5 seconds default timeout. It also has memory limit. To expose it to web, we have to use AppGateway, which is expensive and has its own way of deployment(dev/qa/prod). Sometimes I want service other than simple request/response like WebSocket, Cron, Subscription to MQ. Although AWS lambda sort of provide those functionality, I feels more natural to just set up a box. There are other obvious issues like cold start, no local state(no keep-alive, no internal cache, no connection pool), price(expensive when directly compared to ec2 or onprem server), deployment(need to deploy each function).

I am also curious to know!!

I guess you meant "Zalando", right?

Maybe there wasn't for them. Maybe their app wasn't big enough

I think it's the matter of cloud service marketing to hype the microservices, and then their tools will be make sense and they start making money. Nothing wrong with moonlit as long as you know how to scale up that, heck can you imagine if SAP breaking down to microservices.

Why i should care what Zolando CTO says? What you have done here is just a appeal to authority fallacy.

Our talented editors use Adobe Illustrator and Adobe After Effects.