This presentation covers key factors for API design and adoption for the new class of enterprise application services. Topics include funding, design rules, usage, management and governance.
Be a pessimist – assume everything fails and design backwards. Love your chaos monkey Graceful error handling and retry logic is a must! Make your applications/APIs robust! (sorry for the rhyme.)Expect and handle scenarios like “what if this disk my application is writing to suddenly wasn’t there?”… or is writing to disk even necessary? Maybe a form of cloud storage is a better option.Put your eggs in multiple baskets – leverage multiple providers, geographic regions and availability zones to accommodate for local availability issues. Design for portabilityFor portability between clouds, design your apps/APIs to be loosely coupled. At a minimum, interactions with proprietary cloud APIs implementations should be wrapped and injected. As a developer this is necessary so when your boss wants you to migrate an API to a different platform (or support multiple cloud providers) you can actually pull it off.“What’s that? I need to migrate my service’s caching layer to use a different distributed cache? No problem! I properly decoupled the layers of my application so I can easily swap in an implementation that makes use of the new platform’s cache API.”Think efficiency - inefficient designs will not scale. Efficient designs become cheaper as they scale. Also, inefficient designs cost more money to run in the cloud because they consume more resources, and are therefore more likely to force elastic scale out to occur sooner. It is more important than ever for developers to pay attention to following best-practice with regards to memory and resource management in code.But not too paranoid – not every application needs the platinum solution. Architect for different SLA’s, service tiers and security levels(The above point ties back to your slides regarding maturity model: Ideally, as an organization, your first foray into cloud application development should not be with an application that requires a “platinum solution”. Walk before you run.)
Divide and conquer - pursue data partitioning and parallelization wherever possible. Make components as small and portable as possible including multiple small database instantiations per services package. Use load balancing between layersSmall portable components can help get better utilization of instance resources because you can more densefaster startup times when scaling out new component instancesThink elasticity - increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the same effect. Stateless services are important here. Stateless services scale easier, and applications not originally developed with cloud in mind can have trouble effectively maintaining state across elastically scaling instances/environments.
Keep it loose - loose coupling, service interfaces, separation of concerns, abstraction and well defined API’s deliver flexibilityFrom a developers perspective, this may be the most key point. SOA may be turning into a four letter word nowadays, but following these good practices will reap benefits in the cloud. For devs, this is still where a lot of the magic happens. It helps enable many of the other bullet points in this list.
Discuss Service Bus & Service Registries
why REST is winning the battle for API supremacy:Easy to understand and code against Faster innovate, and faster to market. Less time with plumbing.Http protocol No proprietary protocols means more portable(Although SOAP service stacks support Http, SOAP services are also often hosted over TCP or pipes protocols that don’t always translate well between vendor stacks. HTTP is well known to all.)
