Databases for integration is a terrible idea

Even though Databases as integration end points is a terrible idea. yet, we still see implementations.

dbsforintegration

For example: there is a CRM for the enterprise that is being used for the last 10 years. Every integration with the CRM has been done with a materialized view or direct access to the database tabes for integrating other applications and services. Well, the day has come and enterprise decides to change/ upgrade the CRM. But, this will have affect on all the integration points and there will be breaking changes. Also, it is not possible to do any audit trails, rate limiting or security checks for direct access to databases.

Moreover, there doesn’t exist documentation for the views and access to tables except the DB admins take a look at the users and ACLs.

In many words, using databases for integration is a terrible idea. Instead you should embrace services as integration mechanism.

Jeff Bezos, CEO of Amazon, have the following email sent to the developers:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be fired.

7) Thank you; have a nice day!

Principles, Practices and Constraints

principlesPrinciples are abstract set of related ideas. Practices, on the other hand,  are concrete actions and implementations that supports principles.

For same set of principles there might be different practices. ie: for the same principles there might be different practices in .Net community or Java community.

And then we have constraints that restricts our activities. While practices are not strict and can be bent, constraints are the other way around.

Our problem is we focus so much on practices and constraints then we actually forget about the principles. Instead we should always focus on the principles, use necessary practices and embrace constraints. So that, we can come up with better solutions, innovate and optimize.

 

 

Robustness principle for microservices

Robustness principles by Jon Postel can be applies to microservices.

The principle says:

Be conservative in what you do, be liberal in what you accept from others (often reworded as “Be conservative in what you send, be liberal in what you accept”).

snappyApplying this principle to microservices, we need to be conservative while exposing our services and end points to outside however, be liberal in what we implement within.

Having different services exposing their contracts with different interchange models, it can be a quite messy and challenging for integration. Using a unified interchange model should help.

You should pay attention to integration between services but you can be liberal within your services.

Occam ’s razor for software development

220px-William_of_OckhamThis problem solving principle (law of parsimony) is attributed to William of Ockham .

The principle can be interpreted as: “Among competing hypotheses, the one with the fewest assumptions should be selected”. There are several areas of science Occam’s principle is applied to, from medicine to scientific methods. Occam’s razor principle says that the simplest explanation is usually the correct one.

How can we apply this principle to software development?

I would say “the simpler solution is usually the correct one”. There are two types of complexity while we are developing software, one of them is inherent complexity, and the other is accidental complexity. Inherent complexity arises due to the nature of the business domain itself. Accidental complexity is the one that we create ourselves. Upon facing challenges we usually make decisions and intentionally or unintentionally we create accidental complexity. Applying Occam’s razor to our problems, choosing the simpler solution is usually the correct one. Based on my experience, this is almost always true.

Our solutions should be concise, comprehensive and coherent. Simplicity is essential, however achieving simplicity can be difficult.

It seems that perfection is reached, not when there is nothing more to add, but when there is no longer anything to remove. – Antoine de Saint-Exupery.

That’s been one of my mantras- Focus and simplicity. Simple can be harder that complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it at the end because once you get there, you can move mountains.– Steve Jobs.