Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Learn from SOA: 5 lessons for the microservices era

Matt McLarty | June 30, 2016
The rise and fall of SOA can teach us much about making the best use of microservices

1. Stay true to the goals. The SOA movement went off track when it strayed from its original goals of increasing agility and reducing costs. Implementers focused too much on the technologies of SOA and too little on the business problems they were trying to solve. When the SOA manifesto was published in 2009, it was in reaction to the mainstream SOA movement rather than an embodiment of its principles. Although business alignment is a stated characteristic, the microservices movement runs a risk of going off course. There are already examples of technologists concluding that if they simply containerize their applications, then they are "doing microservices." In order to be successful with microservices, we must focus on the goals, intended benefits and principles before considering the enabling technologies.

2. Start with success. Despite the incredible uptake of SOA in its heyday, there were few public case studies demonstrating its promise. Tellingly, SOA began as a purely conceptual pattern defined by an industry analyst. In contrast, microservice architecture was derived from real software development patterns observed within numerous organizations. Amazon and Netflix are but two flag bearers of the style. Furthermore, the scope of microservice architecture is deliberately broad, covering the patterns, principles, culture, and organizational traits in addition to technologies. This is healthy, as it favors reality over an idealistic model. As the reference microservice implementations change, the model should evolve.

3. Perspectives matter. There are a number of examples in the SOA movement of conflicting intentions leading it astray. Technology executives built centralized empires rather than instilling a cultural change. Enterprise architects insisted on standardization without clear goals. Vendors changed the definition of ESB to fit their products, rather than the other way around. From the architects who are still sore about the original SOA definition being lost, to the vendors looking to rebrand their products yet again, to the enterprise IT shops heavily invested in SOA middleware, those with an ax to grind against the SOA movement are understandably wary of microservices. However, don't convict microservices on the evidence against SOA. Be open-minded and listen to all, but make sure you check your sources. Question everyone's motives, including your own.

4. Seek harmony, not absolutes. SOA started off with balanced goals, such as speeding time to market while reducing integration costs. Stemming from its centralized roots, the SOA movement abandoned both of those goals in practice, instead seeking to control and standardize application integration. This was an extreme and unbalanced position. The essence of the microservices movement is to improve software delivery speed and increase system safety as scale increases. These are harmonious goals. However, given the decentralized heritage of microservices and its agile roots, there is a risk that implementers may stray toward too much team autonomy and compromise the safety side of the coin. There are already examples of this in the industry. The important task is to ensure there are counterbalances in place that support the goals and abide by the movement's core principles.


Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.