Microservices – What have we learned ?

Yesterday, I shared some of my thoughts on serverless architecture  and ended up getting a lot of feedback and a lot of it went back to SOA and then logically on to Microservices. So I thought it may be worth penning some thoughts on this topic as well. Microservices are not a fad – they get used quite a bit today across big important companies, although perhaps not very consistently. Also, I think we have enough experience by now to calibrate our expectations compared to a few years ago.


What is microservices architecture?

I am sure there is an official definition out there somewhere. But a simple way to describe it is as a way to design a solution as a collection of services, each of which does one thing quite well independently. Each service is its own thing – own process, implementation, language etc . The collection of such services that solve an end-to-end problem is then orchestrated with a lot of automation capabilities to form an application.

Why is this a good thing compared to a “monolith” architecture ?

Separation of concerns is not a new idea in designing systems. Microservices architecture is built on this principle. The traditional way of building an application includes a front end ( html/js) , a database ( SQL/NoSQL/File/…) and App server to handle logic. When we hear people criticizing “monolith” apps – they are usually referring to the serverside logic built as a logical whole.

Monoliths are not bad per se – they can be designed and implemented in a modular way, and can scale with the help of good design using load balancers etc. Just that when it comes to scaling, testing etc – you have to deal with the whole even though only a small part needs to change. As cloud becomes more and more the default deployment option, the flexibility to scale and change quickly becomes a bigger need than in the past. Microservices is a very good way to deal with it. Many monolith systems will co-exist with the world of Microservices .

How micro is a microservice ?

This is one area where the wisdom from actual projects tend to throw cold water on the theory and philosophy of microservices. The tendency for many engineers is to go super granular in service definition . Almost without exception, everyone I know who started with this approach has regretted it and agreed to start with fewer services and then break them into smaller chunks over time. The operational overhead is quite significant as you play with tens of services – you now have to maintain and monitor several services, and at some point there is a performance penalty for too much communication across a bunch of services that all do one little thing.

Another interesting aspect is whether your system needs to behave more in a synchronous fashion or an asynchronous fashion. When you break the system into smaller chunks, essentially you are favoring asynchronous communication between them. Then if you need to make it work in a synchronous fashion – you may question your granularity decision quickly.

What about the product/project team?

I have seen several ways in which teams are organized , and have spoken to folks who worked in such teams where I had no direct involvement. There are a few consistent themes

  1. The need to communicate frequently and freely is a make or break criteria, way more than traditional approaches. With great flexibility comes great responsibility !
  2. One big advantage that comes with microservices is that each service can be implemented with a different fit for purpose language. And each service might choose a different database for persistence. While that is all great in theory, just because you can should not translate to you should. For large projects – too many technology choices leads to diminishing returns. Choose wisely !
  3. There is practically no good way to hand off to an ops team when dev is over. Microservices forces a DevOps culture – or at least DevOps tooling for sure. Its probably a good idea to get EVERYONE in the team some training in tooling. You need different muscles for this world than dealing with a Tomcat cluster. The promise of CI/CD needs a highly trained, high performing team. I may even venture to say that best practice is to have the same team that builds the team to continue to support and enhance systems built on microservices. There are just too many moving parts to effectively transition to a completely new team.
  4. There is no substitute for experience. There are not enough highly skilled folks around , so the ones you get need to carry the weight of mentoring their less experienced colleagues. Written standards might not be enough to overcome this. A common observation is two services looking at the same business object – like a vendor object that is of interest to an accounts payables service and a compliance service – and interpreting the semantics differently. Only with experience can you catch this early and converge.

Is it truly easy to make changes compared to monoliths ?

If you are a microservices fanatic, you probably are well versed in all backward compatibility tips and tricks, and hence your answer has to be YES. I will just say that there are some cases where you wish you were working in a Monolith, especially when faced with pressing timelines. A good example is the changes many apps will need due to GDPR  . When multiple services need new functionality – you need to wrestle with the best approach to get this done. Would you create a new service that others can call ? Maybe a common library? Maybe change each service and make local changes? Each has obvious penalties. No silver bullets – decisions taken in designing the app will dictate whether you buy aspirin from Walgreens sized box or Costco sized box 🙂

What about monitoring, testing, debugging etc ?

All the overheads on these topics that comes from distributed computing are in full force here. This is one area where the difference is significantly more noticeable than in the monolith world. Many of us are fans of doing Canary releases . You should have some consistent philosophy agreed on upfront for release management. Whether we admit it explicitly or not, lean and fast deployment has a tradeoff with testing effectiveness. Essentially you are relying more on your ability of montiring your app ( via all the services and messaging frameworks and redundancies) and making quick changes vs trusting impeccable test results . This is a significant change management issue for most technology teams and especially their managers.

So is microservices architecture a safe bet for future ?

There are plenty of public success stories today of microservices implementations – and conferences and tech magazine articles and youtube videos and all that. All Major SIs have expertise in implementing them. So in general, I think the answer is YES. However, I am not sure if microservices over time will be any less frustrating than monoliths in how they evolve. I probably will get some heat from my purist friends for saying this – but perhaps one way to smoothen the journey is to start with a monolith as we have done in the past, then as it evolves – perhaps have services that call the monolith’s APIs. And as you learn more, break down the monolith to a full set of services. I am not saying this because I am a non believer – I am basing it strictly on the talent available to do full justice to a pure microservices based architecture in a mainstream way. Just because Netflix did it does not mean everyone can. In any case – the mainstream pattern in large companies any ways is to start with their old monoliths and roughly follow the approach I mentioned.


Will SAP get a second chance to create a good first impression with mobile developers?

I was part of the judging panel on Thursday for SAP’s HANA innojam at Palo Alto. And I had a chance to think about it some more on my plane ride back home Friday morning. Thanks to turbulence, I did not get a chance to write this during the plane ride as I usually do, so I am doing it now – cuddling with my little daughter and our 2 dogs on the sofa.

At least 3 senior guys at SAP – Jim Snabe, Vishal Sikka and Sanjay Poonen – have me convinced over the last year that they will do something about making the developer ecosystem whole. I have a ton of respect for all three, and I am sure they will do the needful. But as I think more about this – it does feel like quite a steep climb for SAP.

First things first – how do you get a developer started?

As Tobias Hoffman mentions in his awesome SCN blog scn.sap.com/community/portal/blog/2012/03/09/why-makes-sap-this-so-complicated , SAP has a lot of road to cover to even get developers access to all of its software. SAP are not just waking up to these issues – they have been aware of this at least since Sybase acquisition.  And a lot of analysts and bloggers have been harping on this for a while.  Granted SAP is a big company, and have legal challenges as we are often reminded- but if IBM, ORACLE and MS can all do it, it is hard to make a case that SAP has to do something that has never been done before in the industry.

SAP can do the developer outreach incrementally or in an all-out fashion. I am not holding my breath on SAP going all-out since it has a nice annuity from maintenance, and a large corporate inertia to over come. But they have made a bold statement  that their vision is to have millions of mobile developers. Other than partnering with Adobe and Sencha and others who have millions of developers ( majority of whom probably have no interest in the enterprise world SAP operates in) – I cannot see how SAP is going to get to that number, and in what time.

Who should SAP target ?

Some time ago, I had already outlined my thoughts on how SIs fit into this picture.  https://andvijaysays.wordpress.com/2011/12/21/sap-mobility-solutions-should-sis-play-or-stay-on-sidelines/ . My thoughts have not changed much on that front.

There are 2 constituencies of developers in my mind, of course with some overlap, that SAP needs to cater to.

First Group – the bird in hand

This is the traditional community that plays primarily with netweaver and business suite. For this group – their major concern is to see if all the cool new stuff that comes out of SAP will solve some problem they already have in their projects. Generally, I expect majority of them to do consulting/enhancements type work – and less of product development with SAP.

At the moment, SAP is only trying to attract the first group in my opinion. It is probably the right first step for SAP. The good thing with this group is that they are already very passionate about SAP, and they provide a path of least resistance for SAP to get to a large number of developers. There are exceptional independent consultant types in this group who would appreciate better access to systems to keep up to date with skills. The rest are customers and SI/ISV types who generally have some way of downloading software and playing in their company sandbox via . They participate eagerly in innojams/demojams and generally will try out anything SAP throws at them on technology front. I count myself squarely in this group.

Generally this is not a group I would bet big on to create a large number of “products” based on SAP’s technology. They will mostly contribute to incremental addition to existing license revenue. More over, this is a group that already knows many work arounds in SAP – and might not need Gateway or SUP to make mobile applications.  They are also generally weary of SAP’s existing licensing model, and the speed at which SAP moves on these topics – so their instinct might be to not even try commercializing mobile apps. But they are still a viable group for SAP to target as a first step. If SAP makes access to software easy for them – via downloads or a hosted environment, or a combo of both – this group will do all they can to keep the old SAP flag flying high. With this group, it is SAP’s game to lose, unlike the next one below.

Second Group – tempted to say two in the bush, but may be not…yet 🙂

This is the zillion other developers who mostly don’t know much about SAP, but are up to speed on a variety of non SAP technologies. These people typically have a product mindset – and not a project mindset.

If SAP needs to make it big – they need to make it worth the trouble for the second group of developers to jump into the ring. This group needs a subset of everything that the first group needs for access to software, but in addition they will need to see a rapid path to monetization. From mobility side, Apple has set the bar high with their development ecosystem. It has an easy-to-understand way of how to build an app and make money off it. Any model more complicated will make it near impossible to attract this group to SAP.

While we are on the topic – I wonder if SAP’s mobile store is the way to go for selling mobile apps. If I have a smart phone – my instinct is to check the app store I have for SAP mobility apps. I might not even be aware of SAP having its own app store.  May be it is enough to have a free SAP shopping app on things like itunes which points to what all SAP has to sell.  But then, Apple might not like that at all.  I have to think through this some more – but curious on your thoughts on how you see people buying SAP apps in future.

Innojams/demojams – can they help?

SAP has a neat idea to generate developer interest with innojams and demojams. At the moment, only the first group of developers takes part in jams.  However, jams in its current form have limited utility in the bigger picture. Innojams definitely stir up the pride and technical curiosity in developers . But then what? once you present on the big stage, or you win the prize – there is not really a real second step, that I know of, to take it forward. Also, the world outside the first group hardly knows about innojams today. It will be good to expand the reach of innojam to a larger target audience in near future.

What is in it for developers any way?

I cannot stress enough on the licensing and monetization model to be figured out upfront – without that, access to software is practically meaningless. Developers have a lot of choice today, including many OSS choices. SAP needs a compelling story for them to use SAP technology. With the announcement of the VC fund for HANA – SAP has shown that it is serious about this. But I could not understand why they would want to restrict such a fund to just HANA as opposed to all SAP technologies for DB, mobility and cloud. End of the day – isn’t the value of DB+Cloud+Mobile together better than just DB alone?

But not all developers will want to get into the start up business. So SAP will need an additional model to attract the majority who just care about building and selling  many small apps. In this regard, I really liked what they did with the partnerships it announced with Sencha, Adobe etc.  Their model is simple – a free SDK for HTML 5, an MVC paradigm for development, flexible licensing and some paid options, and OData connection with SAP backends.  Like my daughter says – easy piecy lemon squeezy 🙂

Except, we are not sure how SAP handles the licensing/pricing in this scenario . And without that clarity coming real quick – I doubt if scores of developers will jump in and start developing cool apps.  Sanjay Poonen responded on twitter few days ago than SAP will get it right quickly, and I totally  trust him to do so – hopefully by SAPPHIRE in Orlando.