Join Chander Dhall for an in-depth discussion in this video Application development approaches, part of Microservices and Azure Service Fabric Basics for Developers.
- [Instructor] Application development approaches. When it comes to services-oriented architecture, there are two primary application development approaches. One uses a monolithic service, and the other uses microservices. But before we get too ahead of ourselves, let's define what a service is. The best way to think of a service is set of code or functionality that solves a problem, usually a business problem.
The service should also have a well-defined API, so it's easy to be called from another service or utility. It must be independent of other services and, hence, should be able to be scaled as well as upgraded independently. One of the other features of a good service is graceful degradation which simply means that whenever a service that our service is dependent on fails, our service fails gracefully.
For example, checkout service depends on payment service. Rather than failing when the payment service fails, the checkout service should be able to display an appropriate customized error message for such a scenario. And lastly, it is usually built using a specific technology or a specific business domain. Standalone apps. Traditionally standalone apps were the way to go.
In the absence of good architecture, a lot companies wrote monolithic apps. However, these monolithic apps were proven to be hard to maintain and so services have become a popular addition to apps to make maintenance more manageable. That doesn't mean they were introduced right. As you can see in the diagram, the accounting desktop app and accounting web app are using two different web services to talk to the same database.
If we were to update a certain functionality as simple as adding a column to the database, we will now have to update two different pieces of code. Of course, this will create a lot of maintenance challenges and testing overhead. Layered architecture. The next logical step is a layered architecture where there are three layers. One is the graphical user interface, which is the UI layer, the second is the REST API, or the application programming interface, and the third one is the data layer or the persistence layer.
And of course, the REST API is also layered. Without getting into too much detail on architecture, this approach works well. But the problem is that even though it has services that talk to DocumentDB in Azure on a search database on another cloud provider, it's still a monolithic app. The REST API has to be deployed as a whole. The problem with monolithic apps is that they become too big.
Testing becomes really hard. Continuous deployment is out of the question, hence, it's very hard to be agile with them. Sometimes there are very few developers who would even understand the entire app code end to end, and the dependency on them keeps growing. This kind of approach is definitely hard to scale especially with ever increasing business requirements. It also has the possibility of not being able to upgrade to a newer technology stack, and a lot of times a full rewrite may be the only solution which isn't always feasible.
- Reviewing microservices vs. monolithic architecture
- Reviewing microservices and Azure Service Fabric basics
- Programming model architecture
- Creating a stateless service and a stateful service
- Creating a cluster in Azure
- Adding security to a cluster
- Finalizing cluster creation
- Deploying to an Azure cluster
- Debugging an application remotely