christopher bischoff's List: Cloud

• A lot of startups go wrong when adopting cloud services. For starters, cloud becomes a yet another hosting provider with more competitive rates. I have personally seen deployments which are mere fork lifting of existing in-house deployment to a set of virtual machines and storage services. Those who take this road, get frustrated in handling the daily chores of managing their presence on a cloud environment, while some move over to another competitive services. Most of these merely try to make their systems take advantage of cloud environments by adopting certain services or retrofit existing application to a cloud provider. This is the just-being-cloud-ready problem and massive outages of popular services is a signal that needs attention.
• Cloud Native means developing services that truly embrace the nature of cloud environments – which is fragile, failure-prone and scaled horizontal.

• Key Indicators of a Cloud Native Application

   

  The application:

   
   
  1. Is aware of the infrastructure and dynamically scale resources – servers, storage and network etc.
   
  2. Makes fewer assumptions about the users, environment, resources that it works on. This means the software design includes measures for handling large variations in usage, fault in infrastructure, unreliable resources.
   
  3. Has been designed to be aware of the economics of its sustenance. This means its cost-aware and can be configured to make decisions about its operational cost and utilization. This improves the overall cost-to-performance ratio of the application.
   
  4. Is resilient to disaster and can work on degraded mode rather than having a complete outage.
   
  5. Can be deployed across multiple infrastructure options or across hybrid form (private and public cloud infrastructure environments)
   
  6. Is able to be incrementally deployed and is completely testable.

• What Startups Need To Know About Building Cloud Native Applications

   
   
  1. Invest in standardizing the choice of infrastructure and software platform across all environments used for the application – development, test, performance and production.
   
  2. No one size fits all – look out for mixing cloud platform providers by identifying which one works better for your application.
   
  3. Early investment in monitoring and measurement of application, and even tracking cloud outages to help with routing traffic to healthy infrastructure.
   
  4. Building asynchronous communication wherever possible in the application architecture would allow for loose coupling amongst components. Asynchronous behavior is at the heart of cloud native applications.
   
  5. Build transparency across all levels of application to ensure complicated systems could be built on easily.
   
  6. Continuous Capacity Planning – Rather than upfront excessive capacity or under capacity, the cloud native requires just in time capacity and continuous assessment (and automatic) of infrastructure requirements.

• Patterns and Technologies Powering the Cloud Native Way

   

  Reactive Frameworks like Rx and Typesafe are generating strong momentum in adoption amongst development communities and becoming a common way to build applications that are inherently scalable and resilient to failures. A good place to start is visiting the Reactive Manifesto and knowing more on this.

   

  Netflix OSS provides a toolkit for startups to build cloud scale applications without the need for heavy lifting. Netflix is one of the shining stars of public cloud infrastructure usage, and has been at the fore-front of innovation in this space. Netflix OSS is the continuous aggregation of all such best practices in the form of open source toolsets, that is essentially a Swiss Army knife for a startup embracing cloud.

   

  Software containers like Docker enables flexibility for applications across all range of infrastructure – public to private cloud deployments and even regular data center. Together with CoreOS, the operating system that treats containers as first class citizens, it is reshaping how applications are packaged and deployed.

   

  Building on cloud scale means having multiple services orchestrated together to form service behaviors. Microservices architecture is slowly emerging as a championed way to design and built large scale systems. It not only solves the problem for loose coupling and software modularity, but is a boon to continuous integration and deployment. Changes made to one part of the application requires massive changes all across is a bane to continuous deployment, and micro services aims to resolve this situation. Some early microservice PaaS have emerged but are yet to have mainstream adoption. Microservices are also being used to develop Anti-Fragile systems.

   

  Cost aware applications perform continuous monitoring of utilization and the costs incurred. The monitored data is essential to create decision points that the application can use to either scale or diminish the use of resources. Every cloud native application having access to the provisioning APIs means the necessary cost governance must be engineered into them. This opens up to very interesting possibilities.

• Making Reliable over Unreliable

   

  Cloud native applications should have attributes that give them the ability to scale. These apps must have inherent characteristics such a s randomness, resiliency, fail safe capabilties, redundancy and cost optimization These attributes are essential for a software system to not just work but excel at cloud scale. If startups need the scale and effectiveness of a cloud environment, they need to incorporate the essential building blocks of massive scalability  on day one. This means embracing cloud native rather than just being cloud ready.

4 more annotations...

• Just putting an application on Amazon Web Services, Microsoft Azure or IBM Softlayer does not make an application cloud centric. Cloud centric applications are architected for horizontal instead of vertical scaling. Applications are broken into stateless components. Mean-time-to-recovery (MTTR) becomes a more important goal than mean-time-between-failure (MTBF). Cloud centric application architecture has many benefits, including optimization for lower cost, elasticity and high scale. Not every application, however, needs to be 100% cloud centric. Cloud centric architectures have drawbacks too. Examples include data consistency across nodes, noisy neighbors and managing operational data across transient nodes. Nodes, from a cloud development perspective, represent compute or data resource that is largely abstracted by a cloud platform. A node could be a virtual machine, physical server or cluster of servers

• A few key foundational design points will help with understanding cloud centric application architecture. These include:

   
   
  1. Horizontal Scaling
   
  2. Eventual Data Consistency
   
  3. Reduce Network Latency

• Security may not be the biggest barrier to public cloud adoption
   Although the issue of Security is, and always will be, a primary topic for consideration for organizations when considering moving workloads to the public cloud, I am not convinced that it is THE NUMBER ONE barrier to adoption. With a hat-tip to my friend, Chris Hoff, I also don’t believe that survivability is the main barrier to adoption either. By adoption, I mean actually moving the existing full workload from on-premise to an off-premise provider, such as AWS. From my experience, the majority of enterprise applications would just absolutely, flat out, not work in the cloud, period. Many of them are not web apps, and even if they are, they are so intrinsically linked to the traditional “behind the firewall” technologies, such as Active Directory, that the amount of work required and the complexity added to make them function off-premise (with the same performance and supportability) in an alien environment would hit a point of diminishing return so quickly that it becomes apparent to all that it is simply isn’t worth the effort. I’m not considering federation here, so in reality, there are very few opportunities for organizations to do anything other than “learn what they don’t know” in the public cloud – very few can really expect to be able to pick up existing workloads and move them easily.

• Docker accelerates technology adoption, even in conservative organizations

   

  At lunch yesterday,  I spoke with two developers from a large Fortune 500 financial services company. They described how difficult it is to inject new technologies into their environment. Security professionals inside large organizations are designed to say “no” to new techologies, a constant conflict between more progressive groups like developers who like to adopt and use new technologies.

   

  Docker, as a standardized delivery system, pushes the responsibility of resource allocation and security isolation into the container, removing that responsibility from the list of security or operation roles. Though not a silver bullet, this makes it more likely that security teams will approve new technologies if they are only responsible for verifying that the Docker container process is secure. This is a game changer.

• Docker makes it trivial to maintain legacy OS and code

   

  Docker makes it trivial to keep legacy OS, no matter what flavor of Linux you are running. Related to the issue above, many large organizations have aging legacy systems and codebases which they must support. Small new startups don’t have this problem. When I asked Fabio Kung from Heroku and Rafael Rosa about this problem, Fabio noted that Docker makes it trivial to support legacy systems and code. You don’t have to run expensive bare metal servers to host each legacy system. With Docker you get an inexpensive alternative to heavyweight VMs (as long as your legacy system is or runs on a Linux variant). Docker reduces the pain and cost of maintaining old systems and even records that process into a versioned “Dockerfile.”

• Docker rapidly reduces “shipping” pain

   

  Executives and decision makers tolerate CI servers, unit testing, or agile development practices, but they  really care about one thing: shipping code, the last cycle in the development chain, often referred to as “deployment.” Ironically, even with all the tools mentioned above and more, deployment is still a major pain for developers. As Spotify engineer Rohan Singh highlighted to me yesterday, there is still a massive pain point between committing the final tested code and then getting it running on the final production servers. Docker vastly simplifies this final step, and that makes a difference to executives, developers and gets features in front of customers faster.

• Docker solves problems for the Fortune 500 as much as it does for startups

   

  What was most interesting to me as I spoke with people at the conference was how developers from many large organizations saw huge value in using Docker. Docker adoption and development is occurring at such a rapid pace, you would expect it to be something that only startups and early adopters could track, but as it turns out, Docker is quickly showcasing its relevance to both large and small organizations.

2 more annotations...

• Docker is the shell, hermetically sealing an app into a container that runs on Linux. But to make it flexible and useful, Docker needs to work across several hosts and be portable to any cloud environment.
• The need for deeper Docker support is evident in new open-source projects such as Clocker, developed by Cloudsoft. Clocker creates Docker clouds that are orchestrated through Brooklyn, an Apache incubator project, which monitors and manages the Docker containers. Clocker is an open platform designed to manage distributed applications running on Docker hosts. Brooklyn serves as the central nervous system, managing the apps that run in the Docker containers. According to the Cloudsoft blog, the management is through application blueprints, which can be moved between clouds. The blueprints treat the Docker infrastructure as though it is a homogeneous set of virtual machines in a single location. This “Docker Cloud” can make intelligent decisions about container provisioning and placement to maximize resource usage and performance.
• Clocker moves Docker from a single- to a multi-host capability, allowing any public or private cloud to be used as the underlying infrastructure. It means a DevOps engineer or systems administrator can use Clocker with Brooklyn to conduct, in addition, intelligent container placement, which in turn Cloudsoft executives maintain provides resilience, fault tolerance, scaling, optimized resource utilization of hosts and application performance. It further allows deployment of existing Brooklyn/CAMP (Cloud Application Management for Platforms) blueprints to Docker locations, without modification.

2 more annotations...

• Experience: more than just a pretty face

   

  By experience, I mean the combination of relative simplicity of use, with the power and flexibility to solve a wide range of problems. Experience is not just traditional user interface issues, like simple, intuitive screens and so on. In fact, I’d argue that user interfaces don’t have to be exceptional at all.

   

  However, great cloud experiences also include solid programming interfaces (if you intend to allow developers to integrate or extend your service) and human interfaces with your business itself, such as discovery, sales, support and documentation.

   

  Breadth of service offerings, if done well and integrated, can also seriously enhance overall experience. Adding data management, integration, automation and management services to basic infrastructure services is now a cost of entry for the lucrative developer market.

• Ecosystem: Getting the market to build your value

   

  By ecosystem, I mean serving three primary categories of partners:

   
   
  • The customers themselves, who feed back information about the service and related experiences.
   
  • Vendors, projects, and individuals who extend or enhance your service to enable different solution options.
   
  • Expertise partners, such as system integrators, resellers, and even analysts and evangelists that identify opportunities to apply your service to specific problems and/or execute and operate those solutions.

• Ecosystems are important because they extend the ability of your service to address the needs of a broader range of customers — without having to take all of that work on yourself. Yes, a good ecosystem will drive you to enhance your service to meet integration and extension needs, and you may also find yourself competing with successful members of your ecosystem at times.

   

  However, from the customer’s perspective, you’ll only appear to be a safer bet than the competition as a solution to multiple business problems. Ecosystems also create marketplaces where customers feel comfortable that they can shop for, and find, solutions that generally work with their existing portfolio.

   

  The best companies in the cloud are those that address these two categories of problems as priorities and, for the most part, build their brand around them. I am going to use two of them to prove my point. Their longevity is, I think, pretty well established, and I’ll argue that these two focus areas are key reasons why.

1 more annotation...

• I think your assessment is largely correct, in that PaaS is currently just not a mature space at this point. What I hope, is that PaaS vendors focus on application lifecycle management, and allow the IaaS providers (projects) to support their needs with modular services. Frankly, if an IaaS cloud can provide database services, why should the PaaS layer spend time on that requirement? PaaS should be about service composition (or even container composition, if their customers want that), with easy to use hooks into underlying services like DB’s, Cache, etc…

• 1. Build for Server Failure
   Physical machines in the cloud are temporary and they can fail at any time. Your software need to be prepared for server failure. Building for server failure begins with designing stateless applications that are resilient through a server or service reboot or re-launch.

   

  a. Setup auto scaling so that your application can respond to dynamic traffic based on a set of performance metrics.
   b. Setup database mirroring, master/slave configurations to ensure data integrity and minimum down time.
   c. Use dynamic DNS and static IPs so that components of your application infrastructure always have the right context.
• 2. Build for Zone Failure
   Sometimes more than just single servers fail – there are power failures, outages, network failures. Zones (availability zones in AWS terminology) are logical separation within a single physical data center that are engineered to be insulated from failures in other zones.
   a. Spread your servers in each of your application tiers across atleast two zones.
   b. Replicate data across zones.

• 3. Build for Cloud Failure
   On some rare occasions multiple zones in a region can experience outages due to system wide issues. To achieve multiple 9s of availability you need to have a process in place for cloud failures. Interoperability across clouds is difficult due to different APIs, services and configurations.

   

  a. Backup or replicate your data across regions or providers.
   b. Maintain sufficient capacity to absorb cloud or zone failures using reserved instances.
   c. Build high availability across zones and then across regions (across datacenter) and then across different cloud providers.
• 4. Automate and Test Everything
   As you set up your infrastructure to handle server, zone and cloud failure, you should be automating your processes in the event such a failure occurs. Cloud management systems allow you to execute pre-planned failover processes across servers, zones, and clouds. In an emergency, time is precious, so automate everything.
   a. Automate backups so that your data is ready whenever disaster strikes.
   b. Set up monitoring and alerts to identify and pinpoint problems as they occur because you may not receive timely information from your cloud providers.
   c. Your disaster recovery plan is only good if you test it to make sure it works. By directing high loads to your production servers and disabling your various servers, services, and zones, you can test the ability of your infrastructure to withstand failure.

2 more annotations...

• PaaS is in a succinct way possible:

   

  It is PaaS when the infrastructure layer scales seamlessly with the platform layer which, in turn, scales seamlessly with the application.

• When I say seamless, the scaling happens automagically without any need to get the hands dirty. When we build out a platform using various orchestration and configuration management tools, one or more of the following is required:

   
   
  • Even though infrastructure scaling is automatic, platform components like runtime, data store, etc. needs to be scaled separately. This introduces additional layer of complexity and additional overhead in terms of labor. Even though some people might want to use their existing investments on infrastructure tools with PaaS, it is definitely additional overhead while building up from a basic IaaS.
   
  • In addition to Ops overhead, it may require applications to programmatically handle operations which, in turn, implies requirement of newer types of knowledge in the realm of DevOps
   
  • Inside the Silicon Valley bubble, a version of DevOps, where developers have operations knowledge and Ops people code, is taking everyone by storm. Startups in the valley could easily find this talent to build their platform infrastructure on their own using an underlying IaaS offering. But such talent is not easily available elsewhere and, even when they are available, it is expensive
   
  • There is definitely a complexity overhead with IaaS+ approach to platform abstraction but there is also a significant cost overhea

• Many enterprises place prohibitions on the use of Amazon Web Services (AWS), Google and other cloud services, despite the overwhelming evidence that these platforms enable innovation infinitely more than most of internal IT, and are every bit as secure as current systems -- often, more secure.

    

  Rather than the five guiding principles of the COBIT framework that encourage these prohibitions, IT governance should have only one: Exceed stakeholder expectations for agility, innovation, quality and efficiency to drive business value creation
• How is that done while ensuring the proper allocation of capital, the right level of risk management, and while sticking to the service-level agreements demanded by the business? By throwing away convention and being bold; by inspiring your team to let go of preconceptions and fears so they will follow you; by removing people in your team that aren't capable of adapting to this new role of IT.
• Remember that as you implement these changes, there is one driving principle: exceeding the needs of the business and enabling value generation without restrictions.
• Use this new IT governance directive in your recruiting efforts for new talent. Tell them you operate like a Web company and not a traditional enterprise, that developers and operations teams are integrated and are at least twice as productive as they were previously, and that building systems in the cloud is expected and is not a bad thing.

• With the outdated IT governance-driven barriers removed, and a new focus on enabling strategic growth through innovation and agility, the IT department can help drive profitability. They can show that elastic applications running in a usage-metered cloud are cheaper than over-provisioned static applications running at 5% average utilization in the on-premises data center. The business can also profit from newfound automation, which lowers the total cost of ownership for data center services and reduces labor costs.

    

  The new IT governance paradigm must be cloud-driven, innovation-enabling and based on one core principal: Exceed stakeholder expectations for agility, innovation, quality and efficiency to drive business value creation.

3 more annotations...

• It’s more than just technology
  Bernard Golden, VP of Enterprise Solutions for Enstratius, a Dell company 

    

  The biggest inhibitor to more prevalent cloud computing adoption is that organizations are still holding on to their legacy  processes, says Golden, who recently authored the Amazon Web Services for Dummies book. It’s not just about being willing  to use new big data apps, and spin up virtual machines quickly. It’s the new skill sets for employees, technical challenges  around integrating an outsourced environment with the current platform, and building a relationship with a new vendor. “For  people to go beyond just a small tweak, there needs to be a significant transformation in many areas of the organization,”  he says. “Each time there is a platform shift, established mechanisms are forced to evolve.” 

• Regulatory compliance
  Andy Knosp, VP of Product for open source private cloud platform Eucalyptus   

   

  One of the biggest hurdles for broader adoption of public cloud computing resources continues to be the regulatory and compliance  issues that customers need to overcome, Knosp says. Even if providers are accredited to handle sensitive financial, health  or other types of information, there is “still enough doubt” by executives in many of these industries about using public  cloud resources. Many organizations, therefore, have started with low-risk, less mission critical workloads being deployed  to the public cloud. Knosp says the comfort level for using cloud resources for more mission critical workloads will grow.  It will just take time.

• Security and application integration
  Krishnan Subramanian, director of OpenShift Strategy at Red Hat; founder of Rishidot Research 

   

  Security is still the biggest concern that enterprises point to with the cloud. Is that justified? Cloud providers spend a  lot of money and resources to keep their services secure, but Subramanian says it’s almost an instinctual reaction that IT  pros be concerned about cloud security. “Part of that is lack of education” he says. Vendors could be more forthcoming with  the architecture of their cloud platforms and the security around it. But doing so isn’t an easy decision for IaaS providers:  Vendors don’t want to give away the trade secrets of how their cloud is run, yet they need to provide enough detail to assuage  enterprise concerns. 

   

  Once IT shops get beyond the perceived security risks, integrating the cloud with legacy systems is their biggest technical  challenge, Subramanian says. It’s still just not worth it for organizations to completely rewrite their applications to run  them in the cloud. Companies have on-premises options for managing their IT resources and there just isn’t a compelling enough  reason yet to migrate them to the cloud. Perhaps new applications and initiatives will be born in the cloud, but that presents  challenges around the connections between the premises and the cloud, and related latency issues. 

• New apps for a new computing model
  Randy Bias, CTO of OpenStack company Cloudscaling 

   

  If you’re using cloud computing to deliver legacy enterprise applications, you’re doing it wrong, Bias says. Cloud computing  is fundamentally a paradigm shift, similar to the progression from mainframes to client-server computing. Organizations shouldn’t  run their traditional client-server apps in this cloud world. “Cloud is about net new apps that deliver new business value,”  he says. “That’s what Amazon has driven, and that’s the power of the cloud.” Organizations need to be forward thinking enough  and willing to embrace these new applications that are fueled by big data and distributed systems to produce analytics-based  decision making and agile computing environment.     

• cloud bursting by asking whether or not it was real. This led to Christofer Hoff  pointing out that “true” cloud bursting required routing based on business parameters. That needs to be extended to operational parameters, but in general, Hoff’s on the mark in my opinion.

• The core of the issue with cloud bursting, however, is not that requests must be magically routed to the cloud in an overflow situation (that seems to be universally accepted as part of the definition), but the presumption that the content must also be dynamically pushed to the cloud as part of the process, i.e. live migration.

  If we accept that presumption then cloud bursting is nowhere near reality. Not because live migration can’t be done, but because the time requirement to do so prohibits a successful “just in time” bursting approach.

• There is already a requirement that provisioning of resources in the cloud as preparation for a bursting event happen well before the event, it’s a predictive, proactive process nor a reactionary one, and the inclusion of live migration as part of the process would likely result in false provisioning events (where content is migrated prematurely based on historical trending which fails to continue and therefore does not result in an overflow situation).

  So this leaves us with cloud bursting as a viable architectural solution to scale on-demand only if we pre-position content in the cloud, with the assumption that provisioning is a less time intensive process than migration plus provisioning.

• THE ROAD to HYBRID

  The constraints on the network today force organizations who wish to address their seasonal or periodic need for “overflow” capacity to pre-position the content in demand at a cloud provider. This isn’t as simple as dropping a virtual machine in EC2, it also requires DNS modifications to be made and the implementation of the policy that will ultimately trigger the routing to the cloud campus. Equally important – actually, perhaps more important – is having the process in place that will actually provision the application at the cloud campus.

  In other words, the organization is building out the foundation for a hybrid cloud architecture.

  But in terms of real usage, the cloud-deployed resources may only be used when overflow capacity is required. So it’s only used periodically. But as its user base grows, so does the need for that capacity and organizations will see those resources provisioned more and more often, until they’re virtually always on.

  There’s obviously an inflection point at which the use of cloud-based resources moves out of the realm of “overflow capacity” and into the realm of “capacity”, period.

  At that point, the organization is in possession of a full, hybrid cloud implementation.

• LIMITATIONS IMPOSE the MODEL 

  Some might argue – and I’d almost certainly concede the point – that a cloud bursting model that requires pre-positioning in the first place is a hybrid cloud model and not the original intent of cloud bursting. The only substantive argument I could provide to counter is that cloud bursting focuses more on the use of the resources and not the model by which they are used. It’s the on-again off-again nature of the resources deployed at the cloud campus that make it cloud bursting, not the underlying model.

  Regardless, existing limitations on bandwidth force the organization’s hand; there’s virtually no way to avoid implementing what is a foundation for hybrid cloud as a means to execute on a cloud bursting strategy (which is probably a more accurate description of the concept than tying it to a technical implementation, but I’m getting off on a tangent now).

  The decision to embark on a cloud bursting initiative, therefore, should be made with the foresight that it requires essentially the same effort and investment as a hybrid cloud strategy. Recognizing that up front enables a broader set of options for using those cloud campus resources, particularly the ability to leverage them as true “utility” computing, rather than an application-specific (i.e. dedicated) set of resources. Because of the requirement to integrate and automate to achieve either model, organizations can architect both with an eye toward future integration needs – such as those surrounding identity management, which continues to balloon as a source of concern for those focusing in on SaaS and PaaS integration.

  Whether or not we’ll solve the issues with live migration as a barrier to “true” cloud bursting remains to be seen. As we’ve never managed to adequately solve the database replication issue (aside from accepting eventual consistency as reality), however, it seems likely that a “true” cloud bursting implementation may never be possible for organizations who aren’t mainlining the Internet backbone.
• 

4 more annotations...

• One of the key benefits of running enterprise PaaS at scale is incredible insight it gives you into how your developers build and operate your line of business systems.
• Having an accurate and real-time view of your application composition and developer use cases makes problems which are nearly impossible to solve today trivial, almost as a side effect. Governance, compliance, security vulnerability identification, software bugs and yes, feature planning all become incredibly simplified. Once you start doing this at the scale of thousands of enterprise applications, you get statistically relevant insight that you can act on to make your developers and their end users more productive.
• Improved infrastructure utilization is typically the higher profile benefit touted by advocates of shared cloud infrastructure such as multi-tenant PaaS. While significant, it pales in comparison to the developer and application feedback you can use to improve the agility of your team.

1 more annotation...

• On a whim, I asked this audience how many of them saw custom software development as a key part of their IT strategy. I expected about half the room of 100 or so to respond positively.

   

  One hand went up at the back of the room. (It turns out that was someone from NASA’s Jet Propulsion Laboratory. Well, duh.)

   

  Boom. Any discussion about why developers were bypassing IT to gain agility in addressing new models was immaterial here. The idea that Infrastructure as a Service and Platform as a Service were going to change the way software was going to be built and delivered just didn’t directly apply to these guys.

   

  I came away from that experience with a new appreciation for several things that I’m working hard to not lose sight of again.

• 1. It’s the services, stupid

   

  Try as I might, I struggle to remember that cloud computing is more than just recasting IT to better meet the needs of software developers. Part of that is the fact that I live and work in the Silicon Bubble … er, Valley … and work on a product that targets the intersection of IT operations and software development.

   

  But some of it is the insistence that companies selling infrastructure and platform services are targeting “the enterprise,” when in fact they are not and cannot and should not target every enterprise. What AWS and Pivotal and Dell and others are largely targeting is enterprises that are developing software services.

   

  I define software services in this context as software that is designed to be run and accessed over the network, and is built for a dynamic set of consumers (human and/or other software). Certainly if you are building an application for personal use, or for the use of your immediate department, you can leverage cloud, but that’s not the major market opportunity.

   

  So, if you are a business selling cloud platform or infrastructure technologies or services to the enterprise, you likely aren’t wasting much time on these medium businesses that aren’t doing software development. So-called “virtual private clouds” can be used as computing pools in any business, but if they don’t serve developers, they don’t revolutionize the use of IT at nearly the scale as if they did serve developers.

   

  Now, if you offer a software application as a service (aka SaaS), that’s a different story entirely. Common business systems and platforms are where the opportunity is with these mid-sized businesses that don’t write much code.

• 2. Most medium-sized businesses (and probably many large corporate IT departments) are ill staffed to handle the change in operations models that cloud will drive

   

  The scary thing about the transition from a server- or infrastructure-centric operations model to an application-centric model for businesses that don’t do software services development is how radical the shift in required skills will be from one model to the other. Most IT departments were created and staffed (from the client-server era on, at least) to do one thing first and foremost — make sure there are computers available on which to run software that the business requires.

   

  Look at the IT staffs of most non-web businesses. One of the dominant skill sets that has been built up over the years is data center, server, network and storage operations. And, if you lump in operating systems and virtualization (which I consider part of the infrastructure, not the application software), system administrators.

   

  In an application-centric world, deep understanding of switch and router operations, NIC and BIOS configuration, filer configuration, data center cooling and so on give way to understanding how application architectures can leverage the services offered by cloud providers and cloud platforms to combine connectivity, services, consumers, computation and data.

   

  Since those skills are light in many of these organizations, it will probably delay movement from infrastructure-centric to application-centric operations models — which in turn will likely delay the realization of the value of cloud computing to those operations teams.

   

  Furthermore, if the move to software application services increasingly occurs in these companies, it will likely displace many of these infrastructure jobs. The good news is that it will also create many new application-administration jobs.

   

• 3. If you aren’t developing custom services for your business, why the heck not?

   

  Perhaps the most perplexing question to me, however, is why more hands didn’t go up in that room that day. As far as I can tell, the Internet and the power of mobile computing are disrupting every industry (except maybe certain face-to-face service industries, like beauticians or psychotherapists).

   

  Heavy equipment manufacturer Caterpillar provides an online data collection and analytics service to keep track of equipment condition. Early pioneers in online learning platforms included several colleges and universities. Even political campaigns have gotten into the custom software act.

   

  So, is it really true that no new revenue could be generated from at least some simple online service applications? Certainly the effect of mobile on your industry has to have been top of mind for the last five years or so, but what about APIs? Data analytics related to your products or services? Automating your supply chain?

   

  Granted, some of these things might be becoming “standardized” enough to warrant acquiring the capability from a SaaS vendor. But, as has been said time and time again, shouldn’t IT do more than just keep the computers and networks running? Shouldn’t technologists add value to the business by identifying ways technology can expand the business?

   

  That’s certainly not to say that custom software development is for everyone, but it certainly should be strategic for more that just the guys sending one-of-a-kind research instruments into space.

   

  All of that said, I’d welcome your opinion. Do we really understand the differences between selling software services to mid-size manufacturers and selling infrastructure and platform services to online businesses? Should there be more custom software development in businesses that have focused on building data centers to support SAP?

2 more annotations...

• The secure hybrid cloud encompasses a complex environment with a complex set of security requirements spanning the data center (or data closet), end user computing devices, and various cloud services. The entry point to the entire hybrid cloud is some form of End User Computing device whether that is a smart phone, tablet, laptop, or even a desktop computer. Once you enter the hybrid cloud, you may be taken to a cloud service or to your data center. The goal is to understand how the data flows through out this environment in order to properly secure it and therefore secure the hybrid cloud, but since it is a complex environment, we need a simpler way to view this environment.To try and simplify the environment there are three basic goals: 

   
  1. Show the types of places security can be placed
   
  2. Show the type of security that can be placed
   
  3. Show that there is more than one type of security required

• Secure Hybrid Cloud – Transition

   

  Since the main entry point to the hybrid cloud is the end user computing device, we enter into what I have called the transition part of the hybrid cloud.  The transition component of the hybrid cloud holds all those elements that are in effect decision points on where to get or send our users and data. Let us look at each transition component:

• Secure Hybrid Cloud – Clouds

   

  When we look at the cloud components of our secure hybrid cloud we are severely hampered as to what security measures we can implement within those clouds. We often have to trust that the cloud is doing the proper things. That trust is built upon reports about compliance, policy adherence, and written and perceived work flows. There are generally four types of clouds.

• Secure Hybrid Cloud – Data Center

   

  The final part of any hybrid cloud is the data center itself (left side of Figure 1 above) and is the one place where all your security controls for hardware as well as software can live. However, for the data center that is part of a hybrid cloud, that data center is also a cloud of sorts with multiple tenants which could be different organizations, trust zones, or even different businesses. It all depends on how tenant is defined within your organization. If the organization was a service provider, then tenants are customers. If the organization was a government, then tenants would be different departments which may have different security classifications and the cloud itself would fall under the highest classification of data available. Which implies, classification at least is part of the tenant definition. In all cases, there is a need to provide security for some fairly specific components of a data center with respect to the hybrid cloud.

3 more annotations...

• "As engineers we strive for perfection; to obtain perfect code running on perfect hardware, all perfectly operated."
• Netflix "Cloud Native" architecture embraces the Dystopia of "broken and inefficient" to deliver "sooner" and "dynamic".
• Cockroft says that "the new engineering challenge is not to construct perfection but to construct highly agile and highly available services from ephemeral and often broken components."
• Hosted almost entirely on Amazon Web Services (AWS) infrastructure, the Netflix architecture utilises "antifragile patterns"
• These patterns include stateless auto-scaled microservices, reactive APIs, circuit breakers, bulkheads and graceful degradation. Antifragility includes the curious concept of Chaos Monkeys; services that randomly terminate virtual machines in production to test and prove the availability and reliability of the whole system. Cockroft describes how Netflix recently deployed their "Chaos Gorilla" that terminated an entire zone out of their three AWS zones, yielding no perceptible outage for Netflix customers.
• Cockroft describes the architecture as "Cloud Native". "Master copies of data are cloud resident, everything is dynamically provisioned, all services are ephemeral." says Cockroft. The largest services are autoscaled with an average instance lifetime of 36 hours. At the physical level the Netflix infrastructure is composed of thousands of AWS instances supporting auto-scaled micro-services. Some micro-services provide stateless middleware functions while others provide database storage via a quorum of Cassandra NoSQL database instances.
• That replicating "the best" as patterns and reducing interaction complexity leads to an epidemic single point of failure. Cockroft cites the example of the leap-second bug that caused major problems for online services last year. Cockroft suggests that the only way to address these "pattern failures" is automated diversity management and to understand the trade-off between efficiency and fragility.

5 more annotations...

• A hybrid cloud  architecture is then necessary to seamlessly combine an existing  physical/virtual infrastructure or private cloud with the resources  provided by a public cloud. A successful hybrid cloud architecture  should provide the following capabilities:

   
  • helping the user identify application boundaries by discovering  systems that are part of the application and detecting their  dependencies, and then instantiating the entire application in a public  cloud as a single operation (as opposed to instantiating the systems  individually)
  • identifying the configuration of the systems that participate in an  application and intelligently mapping their hardware resource  requirements to the resources offered by a public cloud (for example,  amount of memory, processing power)
  • transparently configuring existing application software stacks,  including the operating system, to run in a public cloud environment
  • enabling transparent and secure access of network services and  applications running in a private cloud by applications running inside a  public cloud (for example, the authentication/authorization service  accessed by an application running in a public cloud may reside in the  private cloud)
  • synchronizing continually, efficiently, and securely the application  software, configuration and data between a private and public cloud
  • providing a public cloud abstraction layer that can be implemented  by multiple public clouds, while at the same time working around  specific public cloud limitations (say, the 1 TB volume limit in AWS)
  • supporting data privacy for data that resides on a public cloud (for example, use encryption)
  • maintaining isolation of applications deployed in a public cloud by  leveraging the mechanisms of such cloud (for example, in the AWS cloud  use VPCs)
   

  Hybrid cloud architectures could therefore address numerous new use  cases that would be difficult to address solely within public and  private clouds.