Microservices! They’re all the rage these days. There doesn’t seem to be a conference or blog that isn’t talking about them (including this one). There’s good reason for all the interest. There are many benefits to using a microservice architecture…but only if you’re ready.
Over the years, I’ve noticed that some ideas stick around, even if their usefulness is suspect. Dijkstra called out one in his famous paper: “Go To Considered Harmful”. These constructs and patterns stick around for many reasons: laziness, lack of experience, or just because it’s part of the language.
There’s another one that keeps popping up: the Pair class.
Unless you’ve been living under a rock in recent years, you’ve probably heard of microservices. For the other three of you, with a microservice architecture you build small, independent applications that work together to solve the larger business process or problem.
Don’t Repeat Yourself. The DRY principle. Write code one time and use it over and over again. While this is great for software development, it doesn’t work so well with people. In my experience, we need a different acronym…FRY: Frequently Repeat Yourself.
You write unit tests right? Unit tests are the first line of defense against bugs creeping into our code over time. But have you thought about the data that you use? Writing tests is a great first step, but if you don’t consider the data used in those tests you may have a false sense of security. If you don’t consider the scenarios I present below, you could have tests that provide 100% code coverage but still let bugs slip through.
High availability is all the rage these days. I’ve written about how it’s a matter of when, not if things will go wrong. We want to build resilient systems, but how much effort should we put into recovering from failure? What is the cost of high availability? How much effort should go into recovering from errors and failures?
I don’t write many JUnit tests anymore. I’ve been using JUnit for years, first version 3 and then version 4. Combined with various frameworks such as Spring, EasyMock, and others, it worked reasonably well. But it always seemed so verbose and almost as much work, if not more, as writing the code itself. So I’ve stopped writing them.
Do you remember learning Object Oriented (OO) programming? You probably learned the basics:
This is fairly standard stuff. But looking back, I’ve noticed something about the examples used to teach OO programming: they don’t exactly follow good design principles! Are we being taught object oriented programming wrong?
Code changes. It evolves over time. Few applications are written and never updated. But not all code changes at the same rate. You may need to make updates to one part of the system while other parts, which depend on the same code, lay dormant, with no need or reason to change. You may not even know all the dependencies of your code, especially if you’re maintaining a shared library!
If you just charge in and make changes without thinking about the dependencies, you run the risk of breaking parts of the system that have no need to change. However, with a little bit of planning, it’s possible to make changes and maintain backwards compatibility with existing code. There are several benefits to keeping things backward compatible:
Software will fail. Your application won’t be perfect when it goes out the door. You can’t perfect something that hasn’t been “finished” and released into production. In spite of all your testing, both automated and manual, there will be problems. Users will exercise features in unexpected ways. Problems with the network or hardware will introduce cases that are hard to test. Developers make mistakes. If you accept this reality, then learn how to learn from failure.