Microservices overview

- [Instructor] Let's start to establish the foundation by discussing microservices. A microservice is not a technology. It's not something that you can download from a website. It's a design principle for building software. The idea is to keep the software small enough, or micro, to be managed by a relatively small team. For example, a team fed by two large pizza pies is a good size to handle a single microservice. A key feature of a microservice is its ability to be developed, tested, and deployed independently of other systems. A microservice's ultimate goal is to simplify the management of a software provided business feature. A microservice supports requirements related to a single business domain. A business domain provides a set of related features to users. For example, an online shopping store consists of several domains, such as payments, customers, and products. The processing of sales transactions can be delegated to the payment microservice. The customer microservice can provide user profile information, and the product microservice can manage all of the catalog information for products to be sold. The microservice is the single owner of the business domain's data managed in some data store. It can provide several input and output interfaces related to the business domain that is used by some external system. For example, the payment microservice can use the customer microservice to get the latest contact information for a customer. The microservice architecture is an alternative to monoliths. Monoliths are large software systems that consist of several components. Managing the payment, customer, product, and all of the shopping needs in a single software system is a monolith. Its ownership may be shared across several teams within a company's business unit. I was once on a large software team, and if I remember correctly, our pizza parties were about 10 to 12 boxes. That team loved pizza. Typical examples of monoliths are software systems that run on mainframes. Mainframes are big servers that are used to run large software systems. They have been trusted by organizations for decades to run their critical monolith applications. You may be asking, well, when should I use a microservice versus a monolith? As mentioned, many monolith solutions have proven to meet business requirements without a hitch for decades. So if you have a fairly straightforward monolith with no real management issues, then you probably don't need a microservice. But there's no promises that you will never need to break down your monolith into microservices. I have witnessed cases where a monolith has been hard to keep up to date. The knowledge of these large software systems may only be known to a few, and leadership may be looking to take advantage of new innovations and technologies that are not compatible with legacy architectures. If this sounds familiar and if you find that your monolith is hard to scale, not performing, too complex, and is very costly, then you may want to consider microservices. But the need for microservices should be driven based on solving a problem that your team is experiencing. This course will focus on addressing micro throughput problems using cloud-native data services. Let's talk about cloud-native data services in our next video.