Reading Time: 11 minutes If it’s not about size, we are left to wonder what Microservices really are. In this chapter we’ll try to figure it out, first by continuing ruling out what it isn’t by taking a stroll down memory lane.
Reading Time: 7 minutes What is the correct size of an application? Maybe before answering it, we better first pose a more important question – why and how it matters.
Reading Time: 9 minutes In this chapter, we’re going to review a use case with a non-beneficial outcome. By it we’re going to finally see the entire picture of what splitting application has to do with Throughputs, Bottlenecks and the Change Stream. And it would end with a twist I made sure you won’t see coming!
Reading Time: 7 minutes In this chapter, we’re going to focus on the ties between cohesion and splitting applications. That is by reviewing another use case of a split done at RapidAPI, an internal one done between the Monetization and the Analytics teams (which was later renamed to Data).
Reading Time: 8 minutes What about splits that are optional? To answer this, we’ve first had to clear out all the hard technical considerations, for that we reviewed the technical/practical musts. But before that, we’ve learned of our development workflow. On how any split affects its Bottlenecks and Throughput. And we’ve seen how splitting deployments and splitting Throughput affect it as well. And somehow everything always had something to do with the frequency of Change and the unsteadiness of the Change Stream.
In the next three chapters, we’re going to put it all together. We’ll be reviewing several use cases, to learn when an optional split would be an eventually beneficial one, or otherwise.
Reading Time: 8 minutes No matter what we’ve done to ease our troubles and coding, the relationship has stayed the same. The persistent data’s structure must always meet our application’s expectations. And it needs to be maintained and managed throughout their life cycle.
With this relationship solid in our mind, we can now add an application that would manage the data for us. Something called a database.
Reading Time: 7 minutes In this chapter, we’re going to review another split that is a technical/practical necessity. This time, we’re going to split away the other end of our backend application, the data. It’s going to persist. By doing so, we’re going to inspect the relationship formed between our application and its data.
Reading Time: 7 minutes We’ve started talking on how to ease those consequences, by reducing the frequency of the need for our applications to Change together. One was rearranging their Modules differently between them, and we ended up seeing there are a lot of considerations to it. In this chapter, we’re going to focus on one of these. By inspecting not physical boundaries, but time boundaries. Because rolling out Changes takes time.
Reading Time: 8 minutes We’ve conveniently been through the entire series the assumption that our two applications are mutually exclusive and share nothing at all. In this chapter, we’re going to start complicating it. This time, with two applications that share a simple client-server relationship. With it, we’ll see how it also complicates our development workflow.
Reading Time: 6 minutes As the relationship between Bottlenecks and Throughput exists throughout our development workflow, it also exists between the engineers and their applications.