As Dreamforce nears and Appirio completes its 6th year as an enterprise cloud solution provider and trusted advisor to technologists everywhere, we wanted to reflect on some of the things we’ve learnt about developing cloud solutions over the years. In this blog, we often focus on the business and end-user implications of cloud computing, but this time we want to focus on what’s different about the cloud for developers and technologists.
Public Cloud Development is Fundamentally Different than On-premise
Public cloud development is fundamentally different than traditional development. There are two inherent things about public cloud platforms that change everything.
The first is multi-tenancy. This means that everyone running a cloud application or platform is on the same underlying version. This has huge implications. In the on-premise world, literally every piece of software is proprietary because it’s designed to work with a particular permutation of application, middleware, database and hardware. Something custom that’s written for a particular version of SAP for a particular customer or site has a very high likelihood of never being used again. Contrast this with the multi-tenant cloud model where everyone is on the same application, running on the same platform, database, operating system, and hardware.
Something you write for Salesforce or Google Apps or Workday can run in any customer’s environment since everyone is on the same version. This means that reuse, which has always been an elusive goal, is not only possible, but also very achievable. At Appiro, for instance, we have a library of 500+ assets that we bring to any project and that gives our teams a big jumpstart. This may sound familiar, but the difference is that these assets aren’t frameworks that need a lot of work to reuse. Many are literally components that can be plugged into the next project. Any rework that does arise is around fitting into a unique business context, never the underlying compatibility of the technology. A few examples – a component that enables you to “check-in” to a nearby Salesforce account, a component that provides dashboards to visualize mail migration errors for Google projects and an application that enables you to store large files on Amazon from Salesforce.
The second big change from traditional applications is that customizations happen through metadata. So, the core application stays the same and customizations can be exported as metadata and shared. When you combine this with multi-tenancy, you get something amazing. Now, anyone anywhere in the world can spin up a developer instance of the cloud application, and if you share your configuration with them, they can have an exact logical replica of your application. This means that it’s now easier than ever for companies to tap into an entire world of developers to solve their specific problems. Our CloudSpokes developer community is one example of a developer community where enterprises can benefit from the expertise of tens of thousands of developers rather than just the ones they happen to have on staff. Other prominent communities include uTest that offers crowdsourced testing and Stack Overflow that offers Q&A on code development. The public communities of the cloud platforms themselves are far more useful than traditional product communities since everyone is talking about the same underlying platform.
Something that’s related to both multi-tenancy and metadata customization is the ability to collect meaningful application and environment data and measure oneself against others. Since public cloud providers collect application metadata and even provide APIs to access that data, it’s now possible to collect detailed data on your application. For example, Appirio collects data across projects on configuration, code and administration complexity, as well as adoption, for most of the solutions we build for customers. This helps us measure not only the quality of each solution, but also enables us to compare each solution against others to make sure that we’re making the right tradeoffs between simplicity and customization.
But taking advantage of these new paradigms means that you have to think differently about application development itself. It’s a shift from thinking of oneself as a developer to thinking of oneself as an architect and orchestrator of development.
The 5 Keys to Becoming a Cloud Architect
- Architect your solution in a componentized way: The key to being a cloud architect is to step away from the mindset of trying to crank through all the functional requirements by yourself. One has to step back and think about the business requirements and then architect a solution of loosely coupled components that address the overall requirements. This takes a bit more work upfront but pays huge dividends later, not only in terms of executing on the initial project but also for maintaining and evolving your solution. This was the promise of loosely coupled Service Oriented Architectures, but the constraints of on-premise software made it nearly impossible to actually work in this manner.
- Value interface (API) over language in your architecture: In past paradigms, IT organizations often defined themselves as Java or .NET shops. That then became the lens through which all architecture and development decisions were viewed. While the intent of driving deeper understanding and awareness of tooling around the development process was admirable, it led to applications being bound together too tightly. The cloud shifts the focus from the language to the service delivered. The whole premise of cloud applications and services is to deliver a service while abstracting how that service is delivered. As a cloud architect, that means you too have to shift your focus from the technology or language to architecting services and the APIs used to access them. This focus will reinforce components and will lead to future-proofing of your application development efforts.
- Drive reuse wherever possible: The next step is to think about the best way to execute each component in your design. There may already be trusted assets out there that you can reuse for some of the components you need. For example, Salesforce makes a lot of assets available through Force.com labs, that you may be able to reuse or adapt. Lots of other cloud providers do the same through open source “labs” assets. If you already have an internal library of assets, that may be an even better starting point. In case you’re not starting from an existing asset and actually need to create a new component, you can save yourself a lot of work by starting with a public cloud PaaS like Force.com or Google App Engine.
- Extend your team with crowdsourcing: For components that can’t be built from existing assets, think about whether you can crowdsource their development. In fact, one of the key values of thinking in components is the ability to create interfaces that allow components to be created in parallel and potentially even in different technologies. So, before you develop, see if the component can be crowdsourced through communities like CloudSpokes for code or 99Designs for UI. The benefit of this approach is that you can get a lot of your application built quickly and in parallel since you’re not constrained by your own team’s capacity. You may also be surprised by creative solutions that you wouldn’t have thought of. This happens to us and our customers with CloudSpokes on a regular basis. Cloud platforms make it possible for many more people to contribute to your success and vice versa. So, in addition to using crowdsourcing, make sure you also engage in relevant communities, whether they’re communities directly related to the products you use or more general developer communities.
- Measure your applications: With cloud solutions, there’s a lot of data available about your application’s configurations, code, quality and more. You can get access to much of this data as an administrator for your cloud application. Start to use the data to build a detailed picture of your application and especially how it’s changing. If possible, try to collect benchmarks on your application relative to others to see where you stand. Some cloud providers collect these benchmarks but not all do, so you may have to do some legwork!
Tell Us How You Think Like a Cloud Architect
Do you have any other tips on how to think like a cloud architect? We’d love to hear from you on Twitter @appirio or in comments!
Chris Bruzzi leads Appirio’s Technology team. His team is responsible for Appirio’s Appirio Services Platform, an integrated suite of applications, assets, benchmarks and crowdsourcing community to enable enterprise cloud development.
Nick Hamm is member of Appirio’s Technology team and is responsible for Appirio’s Cloud Asset Library. He is a Salesforce MVP and has helped over 200 companies across a wide variety of industries transform the way they do business by implementing cloud solutions.