Cloud questions from Syracuse University, NY
A few days ago, I received a couple of questions from a student of Syracuse University, NY who is writing a paper about cloud computing and virtualization. Questions are relatively broad, so I am taking the opportunity to directly post here the answers.
What was the actual technical and business impact of adopting cloud technology?.
The technical impact was a complete rewrite of our codebase. It has been the large upgrade ever undertaken by Lokad, and it did span over 18 months, more or less mobilizing the entire dev workforce during the transition.
As far business is concerned, it did imply that most of the business of Lokad during 2010 (the peak of our cloud migration) has been stalled for a year or so. For a young company, 1 year of delay is a very long time.
On the upside, before the migration to the cloud, Lokad was stuck with SMBs. Serving any mid-large retail network was beyond our technical reach. With the cloud, processing super-large retail networks had become feasible.
What, if any, negative experience did Lokad encounter in the course of migrating to the cloud?.
Back in 2009, when we did start to ramp up our cloud migration efforts, the primary problem was that none of us at Lokad had any in-depth experience of what the cloud implies as software architecture is concerned. Cloud computing is not just any kind of distributed computing, it comes with a rather specific mindset.
Hence, the first obstacle was to figure out by ourselves patterns and practices for enterprise software on the cloud. It has been a tedious journey to end-up with Lokad.CQRS which is roughly the 2nd generation of native cloud apps. We rewrote everything for the cloud once, and then we did it again to get sometime simpler, leaner, more maintainable, etc.
Then, at present time, most our recurring cloud problems come from integrations with legacy pre-Web enterprise software. For example, operating through VPNs from the cloud tends to be a huge pain. In contrast, modern apps that offer REST API are a much more natural fit for cloud apps, but those are still rare in the enterprise.
From your current perspective, what, if anything, would you have done differently?.
Tough question, especially for a data analytics company such as Lokad where it can take 1 year to figure out the 100 magic lines of code that will let you outperform the competion. Obviously, if we had to rewrite again Lokad from scratch, it would take us much less time. However it would be dismissing that the bulk of the effort has been the R&D that made our forecasting technology cloud native.
The two technical aspects where I feel we have been hesitating for too long were SQL and SOAP.
- It took us too long to decide to ditch SQL entirely in favor of some native cloud storage (basically the Blob Storage offered by Windows Azure).
- SOAP was a somewhat similar case. It took us a long time to give up on SOAP in favor of REST.
In both cases, the problem was that we had not been fully accepting the extent of the implications of a migration toward the cloud. We remained stuck for months with older paradigms that caused a lot of uneeded frictions. Giving up on those from Day 1 would have save a lot of efforts.
Reader Comments (2)
I have a question of my own : were you affected in any way by the Azure outage in late february ? If so, did you have any emergency solutions available, or did you just take the loss ? In any case, do you have any practical advice about how to prepare for and how to handle cloud unavailability ?
March 7, 2012 | Victor Nicollet
Hi Victor. Excellent question. Yes, we have been affected by February outage. It was a bad one, and unfortunately not the first multi-day outage for us. We have given really a lot of thoughts how to mitigate the problem in the future. Unfortunately, there is no simple (or cheap) answer to this question. I will try to get back with a full post on this topic.
March 11, 2012 | Joannes Vermorel