Microservices for Dummies
… Anyone who wants to know how this can help your org
Firstly ... Who should be bothered ?
If you are a Business owner/ Division owner/ Channel Owner or anyone who wants or is responsible for a Software system, then this article is for you.
If you are a developer or work in IT, then I would recommend that you need a more deeper (.. read — sophisticated) version of this article
Secondly … Why should one be bothered ?
If you are reading this, then there is a high chance you are planning to build or already own or run a Software System. I won't get into details of why you need software in the first place)
Now once you own one, then you would know (if you dont, you should) that the biggest cost is hidden in the management/upgrading/ bug fixing of the software — not just in terms of expenses on the software itself, but because of loss of opportunities (or) loss of goodwill (or) lack of flexibility (or) lack of ability to respond to changing market conditions.
When someone makes the software, they always think that they have the requirements all figured out. From my personal experience of over 20+ yrs in IT, I can confidently say that its only true at the time of conception of requirements. Even before the system is built, the world changes, your understanding of software changes, and so does your requirements.
Conventional software takes time to change, whether custom built or purchased packaged software, and therein lies the cost.
Microservices are — just as the name suggests, small (micro) software bundles, which, when aggregated forms the whole (functionality). That means, changing a small part of it, shouldn't need you to change the entire software, but just that small Microservice, which is faster to deploy as well — making your business more Agile.
Few initial questions?
Q) Sounds good, so whats the damage?
Well, interestingly, the initial cost for getting software up and running as Microservices is cheaper (some may argue as same same) — but never more — than building a conventional software, as its actually building exactly the same software, with some minor change in concepts on how they are split. Also, a lot of the processes which are manual typically are automated as part of typical MS build.
Cost for maintenance is significantly lower (consider all the above-mentioned losses — software change cost, goodwill, flexibility, promotions etc), compared to any conventional software.
Q) Key question: Can I convert my existing software to Microservices?
Yes and No (in the majority of the cases).
As with most things in life, there is no one straight answer for this question. It will depend on how old the software is, how well it was built, how many knowledgeable team members you currently have on this software, who uses it (external or internal users) etc. In most cases you dont need to really rewrite the entire software, but can be either enhanced with additional capabilities (or) specific functionalities can be split and hosted as separate Microservices. Some examples in question below might help understand this statement better.
Sales Pitch: We assess softwares/ convert legacy software to Microservices based systems. Simply connect for more information.
Q) Thinking again, is it worth the trouble? Throw me some examples …
Depends on the business requirements, let me give few examples —
- One of our customers, needed the ability to add promotions on an as needed basis, which involved customer (or) customer segment specific promotions, market promotions, offers and such in a time senstive manner. The current software involved going back to developers, who took a lot of time (1–2 months) to make this change, as they were combining this with other software changes, by which time these promotions would be worthless (and business is lost of other competitors). Splitting away just the promotion part of product as a Microservice, and hosting as a Self Service (to business) solved this problem.
- Customer portal was to be configured for different types of customers, and for different continents, each with its own customizations. Making a Multi-tenant, Multi-Currency, Multi-language & shared portal, became too complicated to manage, especially to test changes to ensure others are not impacted with new changes. Splitting out each of the portals as a different UI layer (Micro service) each with its own different link, but pointing to the same backend via APIs made changes to each of them much slicker.
- Customer wanted to append an additional invoicing functionality to their current online offering which was currently absent, along with integration into ERP and Financial systems, for Order capture and accounting purposes respectively. Enhancing the software with a new invoicing Microservice integrated with existing software along with additional integration into Financial system made this functionality achievable without having to replace the entire system
- Another customer, wanted to rip and replace a legacy software with a new Cloud hosted solution, providing serious cost saving benefits around IT Infrastructure cost. After due deligence, we proposed to write the whole functionality from scratch upwards. Build from scratch might be a good option, sometimes, where the whole is a collection of Microservices.
and many more…
Q) Ok, sounds interesting, so how do I / where do I start ?
The first step of course is to define the problem in hand, along with what you got currently. Once these two are identified, the next step is to identify a solution and get that agreed, post which the build can be done.
Not the most complicated thing in the world :), while still giving out a world of benefits which in conventional world wouldnt have been achievable.
If you need us to take a look at your problem in hand and go through potential solution options, just connect with us. (Its Free to discuss the solution options)
Whats with the Jargons?
Yes, Yes, before we miss this part, lets cover the jargons associated with Microservices. When you talk to someone, esp in tech, you need to know the jargons. Below are some — “quickies” to help you catchup —
API — These stand for “Application Programming Interfaces”, which in simple words is like doors into a house (yes, just doors, not the house itself), to allow data to come in and go out, and it doesnt do anything else by itself. If you define a good API, implemet with good security, with the actual logic residing inside the house (software), then other softwares can integrate with this microservice, eventually resulting in the whole functionality. One Microservice can have many APIs.
API Gateway — A software which acts as a central gateway for all incoming API calls, typically focussing on API security + validating the inbound API call even before it reaches the API.
DevOps — In simple words, this is the process of automating the Development process to build the Microservice. This doesnt add any functionality to the Microservice, but automates build and deployment of code to servers efficiently. This removes the need for lots of steps and massively increases speed in software delivery — by automating lots of manual steps.
CI-CD — stands for Continuous Integration, Continuous Deployment. Read as executing DevOps to achieve efficiency. Does not add any functionality to Microservice. Read DevOps above.
Cloud — This is just someone else’s computers, aka. servers, with software built on top of it for its management, for e.g. one can launch a new server in a matter of minutes — rather than days or months. The way they achieve this is by already keeping these systems running, and then using Virtualization to expose the systems. There are many Cloud service vendors e.g. AWS (from Amazon.com), Azure ( from Microsoft), GCP (from Google), Oracle Cloud and from numerous small cloud vendors.
Server — Slightly more powerful computer, where software is installed (deployed) and then allows other users to access this software remotely for e.g. via a Browser.
Do let me know if you have more questions or need clarifications.
Author: Dilish Kuruppath, Founder, BridgeApps Ltd., London, UK| Connect via LinkedIn
#Microservices #DevOps #Dummies #MicroservicesForDummies #BridgeApps #DilishKuruppath
We offer Microservices & Platform Consulting and Implementation including DevOps. Do feel free to ask us for more information at — info@bridgeapps.co.uk
