Updated Dec 6, 2017 (Originally Published Dec 6, 2017)
One of the best things about the Laravel Framework is being able to write packages.
Third party packages is the reason that the Laravel Framework has a package facility. However, it is really handy to break one’s own app into packages. My LaSalle Software version 1 was designed to use internal packages.
My experience with version 1 was that it did not take long for the code to get unwieldy. When I added a feature, despite organizing the code well, it became difficult to track down the code that needed updating. There was always so much other code to wade through too, which was quite distracting.
Extracting features into packages made things so much better. I could work on a package without worrying that I would inadvertently break unrelated app features. I could work on multiple packages at once. I could see all the code for the package. I could tag as many releases as I wanted for a package without having to go through a release cycle for the app itself.
Microservices is a product of our times, now that we live in the age of The Cloud. Why have one big app, using packages, when we can break down our app into multiple apps. Each individual app can be optimized according to its size and usage.
Now that The Cloud is accessible and cheap, microservices is as much about the infrastructure as it is about anything else. Sometimes while reading up on microservices I get the impression that it’s really all about the infrastructure. Deploying each app automatically is a big thing. Apps talking to the other apps securely is a huge thing.
I’ve been feeling the growing presence of DevOps as an aspect to software development. This intimate integration seems to have full expression in the microservice architecture. You can’t have one without the other, and each must understand the other. I have to figure out the infrastructure that I am going to use before I write one line of code. My thinking right now is to be very practical about the infrastructure. Despite reading about Netflix and SoundCloud’s implementation, I will take a light touch to infrastructure, as I am hardly building out the new Netflix.
Right now, I am looking at how my independent service apps will securely talk to each other. This is itself a sub-specialty topic.
Once I figure out how my independent service apps will securely talk to each other, I will design my service API’s with an API design tool. Even with a modest number of API’s — perhaps just three or four service API’s — I can see how it can get out of hand without using an API design spec. It’s enough that these tools can generate documentation.
Sometimes, I do think it’s crazy going through all of this just to create a blog. But, clients will want more than just a blog. So this is the way to go.