Don’t believe the salesman. Cloud is not about Service Oriented Architecture or microservices.
Several days ago, I had the opportunity to attend a cloud conference at Google headquarters in Tel Aviv. Something about cloud infrastructures triggers a rewarding system in my brain. Are you familiar with that feeling? It is the same reaction that occurs when shopping online for an electronic device or when I need to start developing new software from the ground up. Utterly, It sounds abusive. But this is the reaction to what the cloud platform marketing is targeting. However, I learned to restrain that urge when designing and developing an enterprise system. This is because the cloud platform doesn’t have my best interest at heart. They can’t because they don’t know me or my challenges. I develop software solutions for General Motors. The software is hosted on the cloud. However, I don’t shape my software architecture on the cloud marketing chopping block. So should you.
If you see a turkey flying in a tornado, it doesn’t mean that turkey flies. The cloud is not about Service Oriented Architecture — SOA or microservices. These practices’ outcome of understanding and designing a product with scalability and maintainability in mind. The cloud came to host your software after modeling it correctly. This relationship is asymmetric. Such a relationship cannot work, and vice versa.
Back in the day, when I worked for Microsoft in the Azure security department, I was assigned to develop a service to crawl, analyze and detect security flaws in customers’ topology hosted on non-Azure cloud providers. What’s unique about Azure’s platform is that it uses Azure to develop and build Azure. That wasn’t the case in its counterpart cloud companies (IBM or Amazon). This model has its upside and downside. I won’t tire you off with this now.
As a major cloud provider, Microsoft gave me a privileged azure account to go wild with what it got. I went wild. I felt like a child in a candy store. My architecture was affected by that too. I enslaved it to cloud storage solutions, service hosting solutions, and encrypted storage solutions. They were so appealing and I didn’t control myself. My brain felt rewarded every working hour of the day. With a clear eye of hindsight, it was rather my lizard brain and not my sanity. Anyway. I learned the hard way that it was all wrong to chisel my architecture with cloud capabilities in mind.
I used Azure functions to build that service. I divided it into four services. One was responsible for crawling the data and storing it, another one was responsible for analyzing and auditing, a third one was responsible for third-party integrations and the fourth one was responsible for auditing and management. I stored each component on an Azure Function and they communicated with each other using the publish-subscriber design pattern via Azure’s EventHub.
Everyone was intrigued by the service design that I presented. I got constructive feedback and adjusted it accordingly. It gave the impression of maintainability because of adopting the SOA paradigm. The design safeguarded the scalability too as it was inherent within the Azure functions. After piping the system into production and monitoring it, I came to realize that the services are chatty functions. With the cloud tariffs today, I will go bankrupt if it wasn’t developed for a cloud company.
Originally published at https://www.linkedin.com.
