Let’s say you have existing applications on-premise, co-location, or private cloud, and an existing engineering team maintaining it. You recognize the benefits of moving to AWS’s public cloud, but how do you get there?
(Watch out for stormy clouds ahead - photo by SpaceX)
The Outside Team
When asked that question, nearly all consultants jump into how to move your application. They’ll talk about lift & shift vs cloud native, microservices, serverless, domain-driven and event-driven designs. They are right to do so; these are important decisions to make when modernizing your applications.
An outside team will build or transform your product on their own and drop it in the lap of your in-house engineers, who are then lost. What is this cloud magic? How does this work?
Here’s the downside. Outsiders now know your product better than your in-house team. Without having developed that deep understanding, they won’t know how to maintain and enhance the work those experts built. Worse perhaps, they will break what was built by reverting to old ways and thus you loose the advantages that the outside team brought.
Big consultancies usually give little thought to your engineers; they are out to sell services and they are motivated to make you dependent on their services. They would have you keep your existing engineers only to maintain your old products as they attrition away. Then you have to keep coming back to the consultancy for more.
Having lead that outside expert team for several consultancy customers, I have seen time and again how ill prepared my client is at the end of the engagement. A few hours of knowledge transfer meetings can’t impart the skills that come from experience.
Use Your Existing Team
Your engineers need to learn how to architect and program the new cloud native way, that’s the only long term play.
Training courses will teach developers the new concepts, but often leave them unsure how to actually proceed with a real enterprise-level project. It then becomes trial and error, and stumbles, as they find their way to something that “works”. Before that first thing works, they will discover something that would have been better, but it’s too late to course correct.
Your developers aren’t bad, but they do learn by doing. As with anything we humans learn, we develop better skills and techniques as we practice. While learning, their lack of experience can lead to the same old problems of costly bills, difficulty scaling, and security holes. These problems can hobble your product for a long time to come, leading to another big redesign effort.
Embed an Expert
A third approach is to embed an individual cloud application development expert into your team. This expert can guide your in-house team and accelerate the project. An expert has gone through this trial and error many times already, so they skip the false starts and go right to a solution for you based on their vast experience.
Embed that expert as a member of your team, and build your new product together. Your engineers learn by doing, you have a product designed and guided by a cloud expert, and in the end your engineers understand the resulting work because they were involved in it every step of the way.
I have had only a couple of “build with” clients in my time at AWS consultancies, and always feel better about the handoff of these projects. I expect these applications to live on and continue to grow for years to come.
Inspired by: Laying Out a Road Map to Close the Cloud Skills Gap - InformationWeek