tag:blogger.com,1999:blog-31536932024-03-14T01:35:50.195-05:00Service Oriented EnterpriseDelivering Business Services through modern practices and technologies.
-- Cloud, DevOps and As-a-Service. Unknownnoreply@blogger.comBlogger582125tag:blogger.com,1999:blog-3153693.post-44678887045719056032015-06-02T07:44:00.000-05:002015-06-02T07:44:37.131-05:00Dominating your career trajectory<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
Here's a copy of a note I sent out to my team @ VMware about continuous learning and being responsible for your career trajectory. </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
<br /></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
--------</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
Team,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
I was having a conversation with one of the practice leads today about a potential new hire. I caught myself saying, "The candidate looks like a Chef/Ruby engineer. Are you sure that the person is willing to grow with us?" It led us to a discussion about how we need to equip our team for the next era of computing. With that in mind, I've assembled my list of twenty things that I think our team should know at various levels. Principals should know all of them; consulting architects should know the vast majority, and so on. With that, my list is as follows:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
<br /></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
1. Be able to explain map reduce, the implementation choices and use cases.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
2. Be able to explain the importance of CAP theorem, and examples of databases that have taken an opinionated approach.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
3. Be able to compare and contrast the differences between virtualization and containers.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
4. Be able to describe the core elements of Microservices and give examples of implementation technology.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
5. Be able to articulate the characteristics and importance of an idempotent service.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
6. Be able to explain how SDN and NFV complement and compete.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
7. Be able to explain block chains and their importance and usage in distributed systems.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
8. Be able to compare and contrast the two major consensus algorithms used in distributed computing and give examples of available implementation libraries.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
9. Be able to discuss the features & design tradeoff's of Google Bigtable and Amazon's Dynamo.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
10. Be able to describe open compute / open hardware initiatives, their goals and examples of available offerings.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
11. Be able to describe the purpose of a fault-injection framework and examples of where and how they have been successfully used.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
12. Be able to describe the elastic scale in/out pattern used pervasively in the Amazon cloud.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
13. Be able to describe the effects of container technologies as it relates to MTTR and overall high availability.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
14. Be able to describe the primary technical components found in a cloud native architecture.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
15. Be able to compare and contrast the PaaS offerings from Pivotal, Microsoft and Red Hat.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
16. Be able to describe all of the major steps in Continuous Delivery, and most common implementation choices in each step.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
17. Be able to discuss the most popular open source licenses and their advantages/disadvantages.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
18. Be able to discuss UI design concepts such as Material UI and Responsive Design.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
19. Be able to discuss modern engineering methods and architectural approaches in detail (e.g., Scrum, BDD, 12 Factor App, etc.)</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
20. Be able to discuss the role of distributed computing cluster managers and schedulers, and examples of their usage.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
I'll admit that this is a big list for even the most accomplished consultant. The observant reader will notice that the primary themes are distributed computing and modern approaches to software engineering and architecture. As the industry continues its aggressive move toward commodity gear, cheap middleware and fast-fail-fast-recover software, we need to be in a position to advise our clients on new tools, platforms, approaches and the business case. A sea of change awaits our clients and we will be called upon to lead them to the next phase of computing. In some cases our employer will have products that solve the problem, and in many cases we'll need to knit together solutions from the greater hardware & software ecosystem.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
<br /></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
Again – this is my list, not the practice leads; I'm confident that they have their own ideas. I wanted to get my view in front of all of you to consider areas for capability development in 2015 and beyond. Of course, many of you have assignments right in front of you that require learning. My recommendation is to be careful not to get lost in the specifics of some product or technology and lose track of the greater change that is occurring. Each of you must dominate your career trajectory. Own it; be its master, not its victim. Learn deep; learn wide; it's not an either/or choice. Rely on your practice leads to help, or me if you feel I can, but ultimately lean on yourself.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
<br /></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; margin-bottom: 0px; margin-top: 0px;">
Thanks,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px;">
<div style="margin-bottom: 0px; margin-top: 0px;">
<br /></div>
<div style="margin: 0px;">
<span style="font-family: Calibri,Arial,Helvetica,sans-serif;"><span style="font-size: x-small;"><b>Jeff Schneider</b></span><span style="font-size: x-small;">, Sr. Director Professional Services, DevOps & Open Cloud</span></span></div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-6478026570561213082014-12-28T18:28:00.000-05:002014-12-28T18:28:04.321-05:00Looking back on my 2014 Cloud Predictions<i>Here's my self-review of my predictions made one year ago:</i><br />
<br />
=-=-=-=-=-=-=-=-=-=-=-<br />
<br />
1. Amazon Web Services will continue to dominate as the leading provider of infrastructure-on-demand services. Like 2013, the number of new offerings will be smaller than previous years as much of the low-hanging fruit has been picked. More emphasis will go into stabilization and features to enable highly reliable computing (across regions).<br />
<b>>> Correct, but this one was too easy. </b><br />
<br />
2. In 2014, we will see OpenStack adoption in the enterprise in a more significant way. This will be both a blessing and a curse. Corporate Infrastructure & Operations teams will be challenged to create stable solutions around OpenStack. The premature release of poor products/code like Ceilometer, Heat and even Neutron will cause unnecessary pain. I&O teams will retreat to the most basic functionality. Those organizations who chose to use the open source bits and not license a commercial product based on OpenStack will rethink their decision. Issues related to a lack of quality and product management will continue to plague OpenStack throughout 2014, leaving the door wide open to VMware.<br />
<b>>> Partially correct. IMHO, OpenStack saw more adoption by service providers while traditional enterprise dipped their toes in the water. And yes, the door was left wide open to VMware.</b><br />
<br />
3. Organizations that were unhappy with the VMware software licensing fees remain unhappy but begin to see it as the 'stable solution'.<br />
<b>>> Correct. </b><br />
<br />
4. The excitement around containers continues to grow in 2013. The Docker model moves beyond early adopters into early majority for dev/test workloads. The way in which Chef/Puppet are used shifts from run-time stack creation to design-time creation, followed by image snapshots. This extends the emphasis on 'idempotent infrastructure'.<br />
<b>>> Correct. </b><br />
<br />
5. As 'idempotent infrastructure' for individual machines begins to feel like a solved problem, the focus shifts to multi-tiered, complex application architectures. A new emphasis is placed on orchestrating full stack solutions regardless of cloud API, hypervisor, operating system and configuration management tool. On-demand, full stack provisioning across dev-to-prod environments becomes doable by your average Joe. That said, TOSCA fails to get any traction due to unnecessary complexity, lack of practical applications and are beat to market by light-weight open source solutions.<br />
<b>>> Correct. We saw a bunch of Docker orchestrators emerge; perhaps too many. </b><br />
<br />
6. More aggressive organizations implement resilience features into their cloud architectures. Systems move beyond the traditional auto-scale and adopt patterns to auto-heal tiers via closed loop monitors that re-provision failed systems and tiers implement run-time service discovery (to reconnect the topology).<br />
<b>>> #FAIL. This was wishful thinking on my part. I need to quit doing that. </b><br />
<br />
7. As resilient architecture become more common, so does the need to test them. Variation of the Simian Army enter the Global 2000; instrumented systems capture data key metrics (MTTR, data loss, etc.) enabling architects to improve the integrity and availability of their solutions.<br />
<b>>> Again, #FAIL.</b><br />
<br />
8. The Hybrid Grid is born. Unlike prior grid emphasis, the focus is on long-running services (not batch jobs). Unlike Hybrid Clouds, the focus is on uniform containers (think LXC/Docker) and resource schedulers that are "service first" not "machine first" enabling the grid controller to offer reputable Service Level Agreements. In 2014, Hybrid Grids gain traction in the high-tech web-scale shops but remain out of reach for most large enterprises. A few small service providers will begin to offer Hybrid Grid as-a-Service.<br />
<b>>> Partially correct. The rise of containers on Amazon and Google Kubernetes or managed containers is pushing this forward.</b><br />
<br />
<br />
9. As we closed out 2013, the Target credit card breach was front-page news. Concerns around security and compliance are increasing in virtually every industry. Removing manual processes is seen as an easy way to implement tighter compliance and security. In 2014, companies will implement sandboxes within their cloud that focus on specific problems like PCI compliance. The DevOps processes will mandate that software 'run the gauntlet' (network segmentation, anti-virus, code inspections, encryption, etc.) to provide a safer environment. More security professionals will singing the praises of the cloud as a means to automate inspections, lock-down environments and provide audit trails.<br />
<b>>> #FAIL. I was thinking we'd see much more SecOps or RuggedOps - but this movement is still early. </b><br />
<br />
10. I anticipate that 2014 will be the year of "cloud in a box", where converged infrastructure solutions and cloud stacks are pre-packaged into turn-key rack/row clouds. Stripped down versions of OpenStack will be the preferred controller. We should expect the usual hardware vendors (Dell, HP, Cisco, EMC, etc.) to offer their own brand, as well as to offer hybrid solutions that leverage hardened cloud software from Red Hat, Canonical and others. Companies that once looked at vBlock or FlexPod open up their wallet. Organizations that avoided converged infrastructure continue to avoid it - but create their own reference architectures for their home-grown kits.<br />
<b>>> #FAIL. Damn. This should have happened by now ... maybe one of my friends at HP, Dell or IBM can comment on why it's taking so long. </b><br />
<br />
=-=-=-<br />
<i>Alright - I didn't do so hot in my 2014 predictions. Most of the stuff I still agree with - but we'll likely have to wait for 2015 or 2016. Here's to being patient!</i><br />
<i>Jeff</i><br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-1106981084892342912014-03-30T12:54:00.000-05:002014-03-31T07:28:35.112-05:00An FAQ on Cloud Consulting Companies<br />
As CEO of <a href="http://www.momentumsi.com/" target="_blank">MomentumSI</a>, I get asked lots of questions about cloud consulting. Here's my attempt to answer some of the most Frequently Asked Questions!<br />
<br />
<br />
<h3>
How do you classify cloud consulting companies?</h3>
The first dimension is 'public cloud' or 'private cloud' (behind the firewall). The second dimension is the technology layer at which they work (IaaS, PaaS or SaaS). The third dimension is the speciality within the layer. For example, a services company might only work in 'public cloud at the SaaS layer' - but specialize in 'sales and marketing' solutions. The fourth dimension is the type of services that they provide. Some companies only do 'strategy and planning', while others will do 'training and mentoring', 'implementation' or 'managed cloud services'.<br />
<br />
<h3>
From a consulting perspective, which clouds are getting the most traction?</h3>
There are lots of clouds across the aforementioned dimensions. For IaaS + public cloud, Amazon is clearly in the lead. For IaaS + private cloud - the company that us selling the most deals is VMware - but the media darling / thought leader is OpenStack with an early lead going to the Red Hat distribution. On the PaaS side, I can't really give anyone credit for dominating the market. From a public PaaS perspective, you'd have to acknowledge Force.com + Heroku (Salesforce.com). On the private side, Cloud Foundry seems like an early thought leader - but it's way too early to tell. At the SaaS layer, we see lots of Salesforce.com, Workday, Microsoft (apps) and Google (apps). There are a ton of others getting traction - too many to mention.<br />
<br />
<h3>
Who are the boutique cloud consulting companies?</h3>
I have to mention my company first, MomentumSI. Our strategy was simple: initially, focus on public cloud (AWS / Google) with an emphasis on automation (think DevOps and Cloud Management activities: ServiceMesh, vCAC, Puppet, Chef, RunDeck, Docker, Ansible etc.) Recently, we're seeing an increased demand for OpenStack and VMware private cloud implementations.<br />
<br />
Other notable boutiques include: Mirantis (Russian firm with core engineering expertise on OpenStack), Appirio / Bluewolf (focused on Salesforce.com), Cloud Sherpas (focused on Google Apps), 2nd Watch and Datapipe (focused on AWS Managed Services).<br />
<br />
<h3>
Are the offshore I.T. companies involved in cloud?</h3>
Yes - but many of them are very early. Companies like Infosys, Cognizant, TCS, Wipro, HCL and EPAM were hired to develop enterprise software, maintain and operate it. They are being asked to help with lift and shift migration efforts - and in some cases, refactoring the applications to work better in the cloud. They focus on migrating 10's or 100's of applications for a single customer. This market is still early.<br />
<br />
<h3>
Are the Very Large consulting companies doing cloud work?</h3>
Yes and no. Many of them are doing true cloud consulting while others are classifying last-generation stuff (e.g., virtualization, hosting) work as 'cloud'. Traditionally, these companies are most commonly used for strategy and roadmap services. CSC, Dell Services and others have made some aggressive moves to build their offering but mostly focused building out their cloud, not on the consulting side. Capgemini made an early push but it's not clear to me if it has turned into a large piece of their business. IBM's acquisition of SoftLayer and subsequent push on BlueMix implies that they're playing to win. I'm confident that Accenture has done something - but I lack visibility into their efforts.<br />
<br />
<h3>
Are the hardware vendors doing cloud consulting?</h3>
I've witnessed Dell getting some interest in their OpenStack offering. I'd speculate that HP public sector will have some consulting drag-along related to data center modernization efforts - and eventually will see opportunities generated from Moonshot and USP. Both EMC and Cisco have access to a wonderful roster of infrastructure buyers. I've seen EMC in some interesting consulting deals; Cisco not so much. Hitachi, Fujitsu and other specialty shops are interested in breaking out of their molds but will likely require a more full-fledged transformation to make the jump.<br />
<br />
<h3>
Who is leading in public sector cloud consulting?</h3>
Despite the fact that I live outside of Washington D.C., I don't follow SLED/Fed. From what little I've actually witnessed, Booz-Allen has had some early wins. The larger defense contractors (Boeing, LMCO, Northrop, etc.) are playing their usual risk averse role. I don't have enough visibility to comment on SAIC, CACI, CGI, etc. ... well, maybe I could comment on CGI ;-)<br />
<br />
<h3>
What are the data center service and hosting companies doing?</h3>
Sungard has made a focused attempt to build out their cloud offerings including vendor neutral consulting. Unisys and Xerox/ACS both made an initial push - but it's unclear to me where the current offerings stand. Many of the traditional hosting companies like Rackspace, Verizon, AT&T and CenturyLink have built out their managed service offerings and will provide 'workload migration implementation'. Generally speaking, most companies in this space are treating cloud like the fundamental threat that it is. They are creating inventive offerings that embrace new partners and approaches. In my opinion, not all of them will make the transition. Those vendors who don't adapt to the customer buying process will be most challenged. Failure to provide unbiased consulting, no hybrid cloud offering, etc. will push customers away.<br />
<br />
<h3>
What are the VAR's (Value Add Resellers) doing in the cloud?</h3>
The VAR's are often the first point of contact for purchasing hardware and software. They realize that if those purchases move to a cloud based model, the potential for disintermediation exists. Several VAR's have begun reselling cloud offerings like it was just another SKU. They leverage their large call centers, shopping portals and existing procurement vehicles/contracts to execute high volume, low-margin transactions. Generally speaking, the VAR's have partnered with focused consulting companies to perform the implementation work.<br />
<br />
<br />
<hr />
<br />
<b>Warning</b>: This is just one opinion. If you need more data, I'd recommend the analysis of Lydia Leong (Gartner), Carl Brooks (451 Group) and James Staten (Forrester); they've all been following the cloud space since the inception. The <a href="http://www.thecloudcast.net/" target="_blank">CloudCast </a>and the <a href="https://gigaom.com/channel/cloud/" target="_blank">GigaOM Cloud</a> sites are also very insightful. Visit <a href="http://www.momentumsi.com/" target="_blank">MomentumSI</a> for more information on our services.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-15104029517036714202014-01-01T15:42:00.000-05:002014-01-01T15:42:03.316-05:002014 Cloud PredictionsGoing into 2014, cloud computing (IaaS/PaaS) is the defacto model for start-ups and SaaS providers. It continues to gain acceptance in large organizations but remains nascent. Looking forward, I anticipate the following:<br />
<br />
1. Amazon Web Services will continue to dominate as the leading provider of infrastructure-on-demand services. Like 2013, the number of new offerings will be smaller than previous years as much of the low-hanging fruit has been picked. More emphasis will go into stabilization and features to enable highly reliable computing (across regions).<br />
<br />
2. In 2014, we will see OpenStack adoption in the enterprise in a more significant way. This will be both a blessing and a curse. Corporate Infrastructure & Operations teams will be challenged to create stable solutions around OpenStack. The premature release of poor products/code like Ceilometer, Heat and even Neutron will cause unnecessary pain. I&O teams will retreat to the most basic functionality. Those organizations who chose to use the open source bits and not license a commercial product based on OpenStack will rethink their decision. Issues related to a lack of quality and product management will continue to plague OpenStack throughout 2014, leaving the door wide open to VMware.<br />
<br />
3. Organizations that were unhappy with the VMware software licensing fees remain unhappy but begin to see it as the 'stable solution'.<br />
<br />
4. The excitement around containers continues to grow in 2013. The Docker model moves beyond early adopters into early majority for dev/test workloads. The way in which Chef/Puppet are used shifts from run-time stack creation to design-time creation, followed by image snapshots. This extends the emphasis on 'idempotent infrastructure'.<br />
<br />
5. As 'idempotent infrastructure' for individual machines begins to feel like a solved problem, the focus shifts to multi-tiered, complex application architectures. A new emphasis is placed on orchestrating full stack solutions regardless of cloud API, hypervisor, operating system and configuration management tool. On-demand, full stack provisioning across dev-to-prod environments becomes doable by your average Joe. That said, TOSCA fails to get any traction due to unnecessary complexity, lack of practical applications and are beat to market by light-weight open source solutions.<br />
<br />
6. More aggressive organizations implement resilience features into their cloud architectures. Systems move beyond the traditional auto-scale and adopt patterns to auto-heal tiers via closed loop monitors that re-provision failed systems and tiers implement run-time service discovery (to reconnect the topology).<br />
<br />
7. As resilient architecture become more common, so does the need to test them. Variation of the Simian Army enter the Global 2000; instrumented systems capture data key metrics (MTTR, data loss, etc.) enabling architects to improve the integrity and availability of their solutions.<br />
<br />
8. The Hybrid Grid is born. Unlike prior grid emphasis, the focus is on long-running services (not batch jobs). Unlike Hybrid Clouds, the focus is on uniform containers (think LXC/Docker) and resource schedulers that are "service first" not "machine first" enabling the grid controller to offer reputable Service Level Agreements. In 2014, Hybrid Grids gain traction in the high-tech web-scale shops but remain out of reach for most large enterprises. A few small service providers will begin to offer Hybrid Grid as-a-Service.<br />
<br />
9. As we closed out 2013, the Target credit card breach was front-page news. Concerns around security and compliance are increasing in virtually every industry. Removing manual processes is seen as an easy way to implement tighter compliance and security. In 2014, companies will implement sandboxes within their cloud that focus on specific problems like PCI compliance. The DevOps processes will mandate that software 'run the gauntlet' (network segmentation, anti-virus, code inspections, encryption, etc.) to provide a safer environment. More security professionals will singing the praises of the cloud as a means to automate inspections, lock-down environments and provide audit trails.<br />
<br />
10. I anticipate that 2014 will be the year of "cloud in a box", where converged infrastructure solutions and cloud stacks are pre-packaged into turn-key rack/row clouds. Stripped down versions of OpenStack will be the preferred controller. We should expect the usual hardware vendors (Dell, HP, Cisco, EMC, etc.) to offer their own brand, as well as to offer hybrid solutions that leverage hardened cloud software from Red Hat, Canonical and others. Companies that once looked at vBlock or FlexPod open up their wallet. Organizations that avoided converged infrastructure continue to avoid it - but create their own reference architectures for their home-grown kits.<br />
<br />
In summary, we should expect the next set of adopters to hop on the wagon. They'll be frustrated by the amount of change and immaturity of solutions. Ultimately, they'll go back to the vendors they know and trust to help them through the pain. The patterns and practices are maturing - but the types of problems that we're throwing at the cloud are becoming more complex.<br />
<br />
The cloud is here; there's no going back.<br />
Happy 2014.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-87390094146293868722013-12-31T09:24:00.000-05:002013-12-31T09:24:12.647-05:00Looking back on my 2013 predictionsLast year, I made some predictions on cloud computing. Here's my self-analysis:<br />
<br />
===================<br />
1. OpenStack continues to gain traction but many early adopters bypass Folsom in anticipation of Grizzly.<br />
<b>>> Correct. This was a gimme. </b><br />
<br />
2. Amazon's push to the enterprise means we will see more hosted, packaged apps from Microsoft, SAP and other large ISV's. Their IaaS/PaaS introductions will be lackluster compared to previous years.<br />
<b>>> Correct. It's interesting that the press failed to notice the lack of interesting stuff coming out of AWS. Has the law of diminishing returns already hit Amazon?</b><br />
<br />
3. BMC and CA will acquire their way into the cloud.<br />
<b>>> Incorrect. CA picked up Nolio (and Layer 7), BMC acquired Partnerpedia. These acquisitions are pieces to the puzzle - but are not large enough to serve as anchors for a cloud portfolio. </b><br />
<br />
4. SAP Hana will quickly determine that Teradata isn't their primary competitor as the rise of OSS solutions matures.<br />
<b>>> Incorrect. SAP Hana continued to kick butt in 2013 and the buyers of it have probably never heard of the large open source databases. What was I thinking?</b><br />
<br />
5. Data service layers (think Netflix/Cassandra) become common in large cloud deployments.<br />
<b>>> Partially Correct. We're seeing the cloud-savvy companies implement cross-region data replication strategies - but the average enterprise is nowhere near this. </b><br />
<br />
6. Rackspace, the "Open Cloud Company" continues to gain traction but users find more and more of their services 'not open'.<br />
<b>>> Correct. Rackspace continues to push a 'partially open' agenda - but users seem to be more than happy with their strategy. </b><br />
<br />
7. IBM goes another year without a cohesive cloud strategy.<br />
<b>>> Correct. The acquisition of SoftLayer was a huge step forward in having a strategy - but from the outside looking in, they still look like a mess. </b><br />
<br />
8. Puppet and Chef continue to grow presence but Cfengine gets a resurgence in mindshare.<br />
<b>>> Partially Correct. Puppet and Chef did grow their presence, especially in the large enterprise. I could be wrong, but I personally didn't see Cfengine get traction. That said, Ansible and Salt came out strong. </b><br />
<br />
9. Cloud Bees, Rightscale, Canonical, Inktank, Enstratus, Piston Cloud, PagerDuty, Nebula and Gigaspaces are all acquired.<br />
<b>>> Incorrect. I was right about Enstratus but some of these predictions were stupid (like Canonical). The others remain strong candidates for acquisition. </b><br />
<br />
10. Eucalyptus sunsets native storage solutions and adopts OpenStack solutions.<br />
<b>>> Unsure; I don't keep track of Eucalyptus. </b><br />
<br />
11. VMware solution dominates over other CloudFoundry vendors.<br />
<b>>> Correct. I was referring to what is now called Pivotal. </b><br />
<br />
12. Cloud 'cost control' vendors (Newvem, Cloudyn, Cloud Cruiser, Amysta, Cloudability, Raveld, CloudCheckR, Teevity, etc.) find the space too crowded and begin shifting focus.<br />
<b>>> Correct. Some of them have moved into adjacent spaces like governance, billing, etc. </b><br />
<br />
13. PaaS solutions begin to look more and more like orchestration solutions with capabilities to leverages SDN, provisioned IOPS, IAM and autonomic features. Middleware vendors that don't offer open source solutions lose significant market share in cloud.<br />
<b>>> Incorrect. I believe this is still coming but for the most part the vendors aren't there.</b><br />
<br />
14. Microsoft's server-side OS refresh opens the door to more HyperV and private cloud.<br />
<b>>> Unsure. This should have happened but I have no data. </b><br />
<br />
15. Microsoft, Amazon and Google pull away from the pack in the public cloud while Dell, HP, AT&T and others grow their footprint but suffer growing pains (aka, outages).<br />
<b>>> Correct. Well - at least the part where AWS, Azure and Google pull away from the pack. Dell continues to frustrate me; I need to have a sit-down with Michael Dell. </b><br />
<br />
16. Netflix funds and spins out a cloud automation company.<br />
<b>>> Incorrect. Perhaps this was wishful thinking. I'm a Netflix OSS fanboy - but think that they're starting to fall into the same trap as OpenStack (aka, open sourcing the kitchen sink without strong product/portfolio management). </b><br />
<br />
17. Red Hat focuses on the basics, mainly integrating/extending existing product lines with a continued emphasis on OpenStack.<br />
<b>>> Correct. Red Hat appears to be taking a risk averse strategy... slow but methodical movement. </b><br />
<br />
18. Accenture remains largely absent from the cloud, leaving Capgemini and major off-shore companies to take the revenue lead.<br />
<b>>> Unsure. I'm unaware of any large movements that Accenture made in the cloud. The big move in the SI space was CSC acquiring ServiceMesh. </b><br />
<br />
19. EMC will continue to thrive: it's even easier to be sloppy with storage usage in the cloud and users realize it isn't 'all commodity hardware'.<br />
<b>>> Correct. That said, we're starting to see companies implement multi-petabyte storage archival projects with cloud companies. </b><br />
<br />
20. In 2013, we'll see another talent war. It won't be as bad as dot-com, but talent will be tight.<br />
<b>>> Correct. And it will get worse in 2014.</b><br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-49524581391343385762013-04-25T10:48:00.000-05:002013-04-25T10:48:24.440-05:00New Presentations: SOA, DevOps and Technical DebtMomentumSI recently published a series of presentations on hot topics in I.T.<br />
<br />
DevOps in 2013 covers the current state of I.T. operations automation and the issues in the SDLC that need to be addressed in order to achieve continuous delivery:<br />
<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0" mozallowfullscreen="" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/18405951" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" webkitallowfullscreen="" width="427"> </iframe> <br />
<div>
<br /></div>
<div style="margin-bottom: 5px;">
By now, most I.T. professionals are familiar with "technical debt". This presentation encourages practitioners to think about the structural issues that slow us down:</div>
<iframe allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0" mozallowfullscreen="" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/19014930" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" webkitallowfullscreen="" width="427"> </iframe> <br />
<div style="margin-bottom: 5px;">
<br />
<br /></div>
A lot has changed in the SOA world over the last few years. However, we continue to see many organizations adopting techniques that don't promote agility:<br />
<iframe allowfullscreen="" frameborder="0" height="356" marginheight="0" marginwidth="0" mozallowfullscreen="" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/17165364" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" webkitallowfullscreen="" width="427"> </iframe> <br />
<div style="margin-bottom: 5px;">
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-72478525810099644562013-01-03T00:01:00.000-05:002013-01-03T00:01:28.371-05:00ITIL and DevOps: Inbreeding?The 2012 Christmas Eve outage at Amazon has people talking. The fuss isn't about what broke; it's about what Amazon said they're going to do to fix it. If you aren't familiar with their report, <a href="http://aws.amazon.com/message/680587/" target="_blank">it's worth a quick read</a>. If it's tl;dr, I'll sum it up: a developer whacked some data in a production database that made the load balancing service go hay-wire, and it took longer than it should have to identify the problem and restore it. (did you see how i avoided the technical jargon??)<br />
<br />
If you're Amazon, you have to start thinking about how to make sure it never happens again. Restore confidence... and fast. Here's what they said:<br />
<br />
<blockquote class="tr_bq">
<span style="background-color: white; font-family: verdana, arial, helvetica, clean, sans-serif; font-size: 13.63636302947998px; line-height: 17.27272605895996px;"><span style="color: #444444;">We have made a number of changes to protect the ELB service from this sort of disruption in the future. First, we have </span><b>modified the access controls</b><span style="color: #444444;"> on our production ELB state data to prevent inadvertent modification without specific </span><b>Change Management (CM) approval</b><span style="color: #444444;">. Normally, we protect our production service data with non-permissive access control policies that prevent all access to production data. The ELB service had authorized additional </span><b>access for a small number of developers to allow them to execute operational processes that are currently being automated</b><span style="color: #444444;">. This access was incorrectly set to be persistent rather than requiring a per access approval. We have reverted this incorrect configuration and </span><b>all access to production ELB data will require a per-incident CM approval</b><span style="color: #444444;">. This would have prevented the ELB state data from being deleted in this event. This is a protection that we use across all of our services that has prevented this sort of problem in the past, but was not appropriately enabled for this ELB state data. We have </span><b>also modified our data recovery process</b><span style="color: #444444;"> to reflect the learning we went through in this event. We are confident that we could recover ELB state data in a similar event significantly faster (if necessary) for any future operational event. We will also </span><b><span style="color: blue;">incorporate our learning from this event into our service architecture</span></b><span style="color: #444444;">. We believe that we can reprogram our ELB control plane workflows to more thoughtfully reconcile the central service data with the current load balancer state. This would </span><span style="color: blue;"><b>allow the service to recover automatically</b></span><span style="color: #444444;"> from logical data loss or corruption without needing manual data restoration.</span></span></blockquote>
<br />
Here's my question: If ITIL Service Transition (thoughtful change management) and DevOps (agile processes with infrastructure-as-code were to mate, what would the outcome be?<br />
A) A child that wanted to run fast but couldn't because of too many manual/approval steps<br />
B) A child that ran fast but only after the change board approved it<br />
C) Mate multiple times; some children will run fast (with scissors) others will move <i>carefully</i><br />
D) No mating required; just fix the architecture (service recovery)<br />
<br />
This is the discussion that I'm having with my colleagues. And to be clear, we aren't talking about what Amazon could/should do, we're talking about what WE should do with our own projects.<br />
<br />
Although there's no unanimous agreement there has been some common beliefs:<br />
<b>1. Fix the architecture.</b> I like to say that "cloud providers make their architecture highly available so we don't have to." This is an exaggeration, but if the cloud provider does their job right, we will have to focus less on making our application components HA and more about correctly using the providers HA components. There's little disagreement on this topic. AWS screwed up the MTTR on the ELB. We've all screwed up things before... just fix it.<br />
<br />
<b>2. Rescind dev-team access. </b>So this is where it gets interesting. Remember all that Kumbaya between developers and operators? Gone. Oh shit - maybe we should have called the movement "Dev<b>Test</b>Ops"! One simple mistake and you pulled my access to production?? LOL - hell, yea. The fact is all services aren't created equal. I have no visibility into Amazon's internal target SLA's - but I'm going to guess that there are a few services that are five-9's (or 5.26 minutes of down-time per year). Certain BUSINESS CRITICAL services shouldn't be working in DevOps time. They should be thoughtfully planned out with Change Advisory Boards with Change Records and Release Windows by pre-approved Change Roles. Yes - if it's BUSINESS CRITICAL - pull out your ITIL manuals and follow the !*@$ing steps!<br />
<br />
Again - there's little disagreement here. People who run highly available architectures know that to re-release something critical requires a special attention to detail. Run the playbook like your launching a nuclear missile: focus on the details.<br />
<br />
To be clear, I love infrastructure-as-code. I think everything can be automated and it kills me to think about putting manual steps into tasks that we all know should run human-free. If your application is two-9's (3.6 days of down-time), automate it! Hell, give the developers access to production data - - you can fix it later! What about 99.9% uptime (8.76 hours)? Hmm... not so sure. What about 99.99% up-time? (52.56 minutes)? Well, that's not a lot of time to fix things if they go wrong. But wait - if I did DevOps automation correctly, shouldn't I be able to back out quickly? The answer is Yes - you <i>SHOULD </i>be able to run your SaveMyAss.py script and it <i>MIGHT </i>work.<br />
<br />
Ponder this:<br />
Dev-to-Test = Use traditional DevOps & IaC (Infrastructure as Code)<br />
Test-to-Stage = (same as above)<br />
Stage-to-Prod (version 1) = (same as above)<br />
Patch-Prod (99% up-time or less) = (same as above)<br />
Patch-Prod (99.9% or greater up-time) = Run your ITIL checklist. Use your IaC scripts if you got'em.<br />
<br />
For me, it's not an either/or choice between ITIL Transition Management and DevOps. IMHO, both have a time and a place. That said, I don't think that the answer is to inbreed the two - DevOps will get fat and be the loser in that battle. Keep agile agile. Use structure when you need it.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-55826762882862124922012-12-31T13:19:00.005-05:002012-12-31T13:19:54.425-05:002013 Cloud Predictions<b>Here's my quick cloud predictions for 2013:</b><br />
<br />
<br />
1. OpenStack continues to gain traction but many early adopters bypass Folsom in anticipation of Grizzly.<br />
<br />
2. Amazon's push to the enterprise means we will see more hosted, packaged apps from Microsoft, SAP and other large ISV's. Their IaaS/PaaS introductions will be lackluster compared to previous years.<br />
<br />
3. BMC and CA will acquire their way into the cloud.<br />
<br />
4. SAP Hana will quickly determine that Teradata isn't their primary competitor as the rise of OSS solutions matures.<br />
<br />
5. Data service layers (think Netflix/Cassandra) become common in large cloud deployments.<br />
<br />
6. Rackspace, the "Open Cloud Company" continues to gain traction but users find more and more of their services 'not open'.<br />
<br />
7. IBM goes another year without a cohesive cloud strategy.<br />
<br />
8. Puppet and Chef continue to grow presence but Cfengine gets a resurgence in mindshare.<br />
<br />
9. Cloud Bees, Rightscale, Canonical, Inktank, Enstratus, Piston Cloud, PagerDuty, Nebula and Gigaspaces are all acquired.<br />
<br />
10. Eucalyptus sunsets native storage solutions and adopts OpenStack solutions.<br />
<br />
11. VMware solution dominates over other CloudFoundry vendors.<br />
<br />
12. Cloud 'cost control' vendors (Newvem, Cloudyn, Cloud Cruiser, Amysta, Cloudability, Raveld, CloudCheckR, Teevity, etc.) find the space too crowded and begin shifting focus.<br />
<br />
13. PaaS solutions begin to look more and more like orchestration solutions with capabilities to leverages SDN, provisioned IOPS, IAM and autonomic features. Middleware vendors that don't offer open source solutions lose significant market share in cloud.<br />
<br />
14. Microsoft's server-side OS refresh opens the door to more HyperV and private cloud.<br />
<br />
15. Microsoft, Amazon and Google pull away from the pack in the public cloud while Dell, HP, AT&T and others grow their footprint but suffer growing pains (aka, outages).<br />
<br />
16. Netflix funds and spins out a cloud automation company.<br />
<br />
17. Red Hat focuses on the basics, mainly integrating/extending existing product lines with a continued emphasis on OpenStack.<br />
<br />
18. Accenture remains largely absent from the cloud, leaving Capgemini and major off-shore companies to take the revenue lead.<br />
<br />
19. EMC will continue to thrive: it's even easier to be sloppy with storage usage in the cloud and users realize it isn't 'all commodity hardware'.<br />
<br />
20. In 2013, we'll see another talent war. It won't be as bad as dot-com, but talent will be tight.<br />
<br />
I try to keep my predictions upbeat and avoid the forecasts on who will meet their demise - but yes, I anticipate a few companies will close doors or do asset sales. It's all part of the journey.<br />
<br />
Enjoy your 2013!<br />
JeffUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-38432858449351364642012-12-29T17:02:00.000-05:002012-12-29T17:02:35.763-05:00AWS Outage: Netflix and Stackato<div class="MsoNormal">
Over the last few days, a few of the engineers at <a href="http://www.transcendcomputing.com/" target="_blank">TranscendComputing</a> have been discussing what we could have done to have helped Netflix
avoid their Christmas outage. For those of you who aren’t aware, AWS suffered
an outage in the Elastic Load Balancer (ELB) service in the East Region.</div>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In the middle of our discussions on creating massively
scalable, highly available, clustered load balancers with feature parity to
ELB, I caught a post by Diane Mueller at Active State. The <a href="http://www.activestate.com/blog/2012/12/what-i-really-didnt-want-christmas-another-aws-outage" target="_blank">gist of her post</a> is
that ‘Netflix went down because of AWS but her personal app (which leveraged
FeedHenry and Stackato’ was revived after 10 minutes. The post seems to imply
that if you use PaaS (like Stackato), one can switch clouds easily, like she did
when she moved to her application to the HP Cloud. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I’ll avoid the overly dramatic retort but let’s just say
that I disagree with Dianne’s implication. Here’s my position: if core Netflix
applications were negatively affected by any core service (such as ELB), it
would be extremely difficult to quickly switch to another cloud. Here are some
specifics:</div>
<div class="MsoNormal">
</div>
<ol>
<li>No disrespect to my friends on the HP Cloud team but I
honestly believe that if Netflix were to have done a sudden switch from AWS to
HP it would have brought HP Cloud to its knees. ELB’s (if they had them) would
have been crushed and Internet gateways would have been overloaded. Finding a
very large number of idle servers may have also been a challenge.</li>
<li>In this imaginary scenario, I guess we’ll assume that
Netflix decided to keep their movie library and all application services
running on multiple clouds. Sure this would be expensive but it wouldn’t have
been realistic for them to do a just-in-time copy of the data from one location
to the other.</li>
<li>Netflix has done a great job of publishing their technical
architecture: EMR, ELB, EIP, VPC, SQS, Autoscale, etc. None of these are
available in the solution Dianne prescribed (Stackato), nor does HP Cloud offer
them natively. There is a complete mismatch of services between the clouds. CloudFoundry
offers some things that are ‘similar’ but I’m concerned that they wouldn’t have
offered performance at scale.</li>
<li>Netflix has also created tools specific to the AWS cloud
(Asgard, Astyanax, etc.) as well as tuned off-the-shelf tools for AWS like
Cassandra. These would have to be refined to work on each target cloud.</li>
</ol>
<br />
<div class="MsoNormal">
In summary, there’s little-to-no chance that Netflix could
have quickly moved to ANY other cloud provider (including Rackspace or Azure)
and there’s not a thing that Stackato would have done to alleviate the problem.
All medium and large customers have real needs that are service dependent. I’ve
joked that CloudFoundry is a toy. It is, but it’s a toy that is maturing and
eventually may help with ‘real’ problems – but let’s be clear – that day isn’t
today. Any suggestion that it is ready for a ‘Netflix-like-outage’ is either
naïve or intentionally misleading. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I’ve spent the last three years working on solving the AWS
portability problem – and it’s a bitch. Like Dianne, if you have a simple app
my solution, TopStack, will work. It replicates core AWS services for workload
portability. As proud as I am as what the team at Transcend Computing has done,
I’m also quick to note that cloning any of the AWS services at massive scale
with minimal down-time, across heterogeneous cloud platforms and providers is
an incredibly tough problem. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Here’s my belief: Running the Transcend Computing ELB
service on HP Cloud would not have worked for Netflix in their time of need.
Our software would have been crushed. HP’s cloud would have been crushed.
Netflix’s homegrown software wouldn’t have had ‘practically portable’. <b>It
would not have worked.</b> <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I’m happy to acknowledge where we suck. We’ll continue to
listen to the unfortunate incidents that AWS, Netflix and others encounter. My
2013 prediction for Transcend Computing is this: we’ll suck less. Acknowledging
reality is the first step.<o:p></o:p></div>
<!--EndFragment-->Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3153693.post-23974202463775781412012-11-24T23:04:00.000-05:002012-11-24T23:04:05.704-05:00What's After Cloud?
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Revision>0</o:Revision>
<o:TotalTime>0</o:TotalTime>
<o:Pages>1</o:Pages>
<o:Words>1053</o:Words>
<o:Characters>6006</o:Characters>
<o:Company>MomentumSI</o:Company>
<o:Lines>50</o:Lines>
<o:Paragraphs>14</o:Paragraphs>
<o:CharactersWithSpaces>7045</o:CharactersWithSpaces>
<o:Version>14.0</o:Version>
</o:DocumentProperties>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
<w:UseFELayout/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->
<br />
<div class="MsoNormal">
As an advisor to some of the world’s largest companies, it’s
my job to keep up with advances in technology.
I’m paid to answer questions like, “what’s after cloud?” I’ve thought a
lot about this very question and I’ve formed my answer: “More Cloud”. I believe that many new innovations will be packaged as 'cloud' and the combined ecosystem of innovation will outweigh other non-server side contenders. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Clouds promote increased automation, computing efficiency
and increased service levels. Public clouds add the outsourcing model, while
private clouds leverage existing infrastructure. Despite the value clouds
offer, investments made in cloud computing by both vendors and buyers have been
insignificant relative to the size of the opportunity. I believe that the next
several <b>decades</b> will be dominated by
a single computing paradigm: cloud. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>From Structured
Programming to Cloud Elasticity<o:p></o:p></b></div>
<div class="MsoNormal">
<i>The magic of cloud is
the ability of a service to provision additional computing capacity to solve
the problem without the user being aware.</i>
Cloud offerings are divided into sub-systems that perform a specific
function and can be called over a network via a well-defined interface. For the
uninitiated, we call this a service-oriented architecture (SOA). Cloud offers a
variety of services such as compute-as-a-service and database-as-a-service. The
service-oriented approach allows an implementer to swap-out the internals of a
service without impacting the users. This concept is borrowed from prior art
(structured programming, OOD, CBD, etc.) While SOA extends prior paradigms to
embrace distributed computing, cloud extends SOA to solve issues related the
quality attributes or non-functional concerns such as scalability and
availability. Cloud services respond to requests from various users/consumers
where each request varies in complexity to the point where the amount
computational power needed to satisfy the request will vary over time. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Encapsulated
Innovation<o:p></o:p></b></div>
<div class="MsoNormal">
The as-a-service model encapsulates (or hides) new
innovations behind the service interface. For example, when Solid State Drives
began delivering fast IO access at competitive prices, cloud storage services
began using them under the covers. When new patterns and algorithms are
invented we see them turned into as-a-Service offerings:</div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
</div>
<ul>
<li><span style="font-family: 'Times New Roman'; font-size: 7pt; text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">Map reduce becomes the AWS Elastic MapReduce
Service</span></li>
<li><span style="font-family: 'Times New Roman'; font-size: 7pt; text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">Dynamo and eventual consistency become AWS
Dynamo / MongoDB-aaS</span></li>
<li><span style="font-family: 'Times New Roman'; font-size: 7pt; text-indent: -0.25in;"> </span><span style="text-indent: -0.25in;">Dremel becomes Google Big Query</span></li>
</ul>
<!--[if !supportLists]--><br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Significant innovations will continue to unfold but the
vehicle for delivering those innovations will be as-a-Service (SOA) with
elastic infrastructure (cloud). Said another way, cloud will be awarded the
credit for innovation because it is the delivery vehicle of the
innovation. This might seem like an
inappropriate assignment of credit but in many cases the cloud model may be the
only practical means of delivering highly complex, infrastructure intensive
solutions. For example, setting up a large Hadoop farm is impractical for many
users, but using one that is already in place (e.g., AWS EMR) brings the
innovation to the masses. In this sense, the cloud isn’t the innovation but it
is the agent that ignites its viability. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Metcalfe’s Law <o:p></o:p></b></div>
<div class="MsoNormal">
A cloud is a collection of nodes that interact across
multiple layers (e.g., security, recovery, etc.) As the collection of nodes
grow, so does the value of the cloud. If this sounds familiar, it’s rooted in
network theory (Metcalfe’s Law, Reed’s Law, etc.) To liberally paraphrase,
these Laws state that the value of the network increases as more nodes, users
and content are added to the network. I’d argue that the same model holds true
for cloud: As the size of a cloud grows (machines, users, as-a-Service
offerings) the value of the cloud grows proportionately. Any solution that is able to accumulate value
in a non-linear fashion becomes very difficult to replace. The traditional
killer of network value propositions is when a new innovation kills the
original, or when the network gets dirty (too costly, too complicated, etc.).
In theory, SOA and the Cloud delivery model exhibit inherent properties that
counter these concerns. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Incremental Funding<o:p></o:p></b></div>
<div class="MsoNormal">
A significant attribute of cloud is that it grows
‘horizontally’. This means that a cloud operator can add another server or
storage system incrementally. Unlike the mainframe, you can grow a cloud by
using small, inexpensive units. This characteristic encourages long-term
growth. Anyone who has had to fight for
I.T. budget will recognize the importance of being able to leverage agile
funding models. It’s more than a nicety; it’s a Darwinian survival method
during depressed times. Cloud, like a cockroach, will be able to survive the
harshest of environments. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Data Gravity (Before
and After)</b></div>
<div class="MsoNormal">
Dave McCrory suggested the concept of Data Gravity: “Data
Gravity is a theory around which data has mass.
As data (mass) accumulates, it begins to have gravity. This Data Gravity pulls services and
applications closer to the data. This attraction (gravitational force) is
caused by the need for services and applications to have higher bandwidth
and/or lower latency access to the data.” McCrory’s concept suggests an
initial barrier to cloud adoption (moving data to the cloud), but also suggests
that once it has been moved, more data will be accumulated, increasing the
difficulty to move off of the cloud. This model jives with modern engineering
belief that it’s better to move the application logic to the data, rather than
the reverse. As clouds accumulate data,
Data Gravity suggests that even more data (and logic) will accumulate. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>The Centralization-Decentralization Debate<o:p></o:p></b></div>
<div class="MsoNormal">
One of my first managers told me that I.T. goes through
cycles of centralization and decentralization. At the time he mentioned it, we
were moving from mainframes to client/server. He noted that when control was
moved too far out of ones control there would be a natural reaction to remove
power from the central authority and to regain enough power to solve your
problem. Of course, cloud attempts to balance this concern. The cloud is usually
considered a centralized model due to the homogenous nature of the data
centers, servers, etc. However, the self-service aspect of cloud attempts to
push power to the end user. Cloud is
designed to be the happy medium between centralized and decentralized; only
time will tell if it satisfies this issue. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In summary, I believe that multiple large innovations are
coming but many, if not most, will be buried behind an as-a-Service interface
and we’ll call them cloud. When I watch TV, I’m rarely aware of the innovations
in the cameras, editing machines, satellites or other key elements of the
ecosystem. From my perspective, TV just keeps getting better (it’s magic). The
cloud encapsulates innovation in a similar manner. In some ways, it is
unfortunate new innovations will be buried by the delivery model but in
fundamentally, it’s this very abstraction that will ensure its survival and
growth. </div>
<!--EndFragment-->Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-10936428814065464102012-11-19T05:47:00.000-05:002012-11-19T05:48:19.190-05:00Amazon’s Cloud: Five Layers of CompetitionMost people would agree: Amazon Web Services is crushing
their competition. Their innovation is leading edge, their rate of introducing
new products is furious and their pricing is bargain-basement low.<br />
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This is a tough combination to beat! How do they do it? </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-size: 14.0pt; line-height: 115%; mso-bidi-font-size: 11.0pt;">The Power
of Permutations<o:p></o:p></span></b></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-nLAsNRboRMs/UKoNrrJtWfI/AAAAAAAAAJg/83kxGj1VNLM/s1600/AWS+Layers.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-nLAsNRboRMs/UKoNrrJtWfI/AAAAAAAAAJg/83kxGj1VNLM/s1600/AWS+Layers.png" /></a></div>
<div class="MsoNormal">
Amazon’s offering takes
a layered approach. New solutions are introduced at any of the Five Layers and
are then combined with the other layers. By creating solutions with interchangeable
parts, they’ve harvested the power of permutations via configurable systems. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-size: 14.0pt; line-height: 115%; mso-bidi-font-size: 11.0pt;">Platform<o:p></o:p></span></b></div>
<div class="MsoNormal">
Take an example starting with a new platform. Let’s imagine
that Amazon were to offer a new Data Analytics service. They’d likely consider
the offering from two angles: 1) How do we support current analytics platforms
(legacy)? and 2) How do we reinvent the platform to take advantage of
scale-out, commodity architectures? Amazon typically releases new platforms in
a way that supports current customer needs (e.g., support for MySQL, Oracle,
etc.) and then rolls out a second way that is proprietary (e.g, SimpleDB,
DynamoDB) but arguably a better solution for a cloud-based architecture. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-size: 14.0pt; line-height: 115%; mso-bidi-font-size: 11.0pt;">Data Center</span></b>:
When Amazon releases a new offering they rarely release it to all of their data
centers at the same time. We’d expect them to deliver it in their largest center:
the AWS East Region where it would be delivered across multiple availability
zones. After some stabilization period, the offering would likely be delivered
in all US regions, or even globally. Later, it would be added to restricted
centers like GovCloud. Amazon is careful to release a new offering in a limited
geography for evaluation purposes. Over time, the service is expanded
geographically. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-size: 14.0pt; line-height: 115%; mso-bidi-font-size: 11.0pt;">Virtualized
Infrastructure</span></b>: The new service would likely use hardware and
storage devices best suited for the job (large memory, high CPU, fast network).
It’s common to see Amazon introduce new compute configurations that were driven
by the needs of their platform offerings. Over time, the offerings are extended
to use additional support services. This might include things like ways to back
up the data or patch the service. Naturally, we’d expect that as even newer
infrastructure offerings became available, we’d be able to insert them into our
platform configuration. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-size: 14.0pt; line-height: 115%; mso-bidi-font-size: 11.0pt;">Cross-Cutting
Services</span></b>: For every service introduced, there are a number of “crosscutting
services” that intersect all of the offerings. Amazon’s first priority is
usually to update their UI console, which enables convenient administration of
the service. Later, we’d expect the service to be added to their monitoring
system (Cloud Watch), their orchestration service (CloudFormation) and ensure
that it could be secured via their permissions system (I&AM). These three crosscutting
services are key enablers to the automation story that Amazon offers. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-size: 14.0pt; line-height: 115%; mso-bidi-font-size: 11.0pt;">Economics</span></b>:
Perhaps the only thing Amazon enjoys more than creating new cloud services is
finding interesting ways to price them. For any new offering, we would expect Amazon to have multiple ways to price the
offerings. If it was for a legacy platform, we’d expect to be billed by the
size of the machines and the number of hours that they ran, and the disk and
network that they used. If it was a next-generation platform, we’d expect to be
billed on some new concept – perhaps the number of rows analyzed, or rows
returned on a query. Either way, we’d expect that the price of the offering
will come down over time due to Amazon’s economies of scale and efficiency. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The Amazon advantage isn’t about any one service or
offering. It’s a combinatorial solution. They have found a formula for
decoupling their offering in a way that enables rapid new product introduction
and perhaps more importantly it offers the ability to upgrade their offerings
in a predictable and leveraged manner over time. Their ability to combine two
or more products to create a new offering gives them ‘economies of scope’. This
is a fundamental enabler of product diversification and leads to lower average
cost per unit across the portfolio. Amazon’s ability to independently control
the Five Layers has given them a repeatable formula for success. Next time you
read about Amazon introducing XYZ platform, in the East Region, using Clustered
Compute Boxes, hooked into CloudWatch, CloudFormation and IAM, with Reserved
Instance and Spot Instance pricing – just remember, it’s no accident. Service
providers who aren’t able to pivot at the Five Layers may find themselves
obsolete.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-33145791776543560992012-06-02T08:04:00.000-05:002012-06-02T09:23:09.258-05:00Why You Really, Truly Want a Private CloudJason Bloomberg wrote a thought provoking article on, "<a href="http://cloudcomputing.sys-con.com/node/2288203" target="_blank">Why You Really, Truly Don't Want a Private Cloud</a>". The article reviews the benefits of public cloud and then challenges the ability for a private cloud to bring the same benefits. Unfortunately, I think Jason's conclusions are wrong. I want to be clear about two things: my day-to-day experience and my potential conflict of interests.<br />
<br />
<b>Conflicts of Interest:</b> MomentumSI consults with organizations on how to select private clouds, install/configure them, monitor, manage, govern and secure them. Transcend Computing provides software that makes the private cloud run more like Amazon. Each company does a significant amount of work in public cloud. We love both public and private clouds.<br />
<br />
<b>My day-to-day Experience:</b> I have teams of consultants and engineers who use private cloud and public cloud on every assignment. They have done so for years. Cloud is their default deployment model. Several of my younger team members have never worked with physical servers/disks/network devices - they only know IaaS/PaaS. <b>Team members switch between public and private clouds like they're switching from a pen to a pencil.</b> They don't think twice about it - they just do it. The reasons why they select one over the other are commonsense to them (and anyone who has access to both):<br />
<br />
<ul>
<li>They run elastic/bursty jobs in the <b>public cloud</b></li>
<li>Most new production applications are run in the <b>public cloud</b> because there is built in disaster recovery, elastic scaling and a global footprint: Availability Zones, Regions, etc.</li>
<li>Pre-production staging environments are done in the <b>public cloud</b> because we want it to mirror the production architecture. </li>
<li>Most of our legacy COTS applications have been moved to the <b>private cloud</b>. We watch them closely, optimize their environments when needed and avoid violating the license agreements which often prohibit their execution in a public cloud. </li>
<li>Most dev/test is done in our <b>private clouds. </b>We run Eucalytpus, OpenStack and CloudStack. Most companies wouldn't do this, but we do given the nature of our consulting. Developers prefer private clouds when they want:</li>
<ul>
<li>Low latency access to their cloud (for themselves or other applications)</li>
<li>Low level probing that filters out multi-tenant noisy-neighbors </li>
<li>Constant booting of a machine (fast and cheap)</li>
<li>More choice in the cloud hardware configuration (Amazon is getting there, but still has a long way to go...)</li>
<li>We see more experimentation being done on the private cloud (fixed/sunk costs). Most team members are keenly aware of the large public cloud bills that they've generated.</li>
</ul>
</ul>
<br />
The reasons why a person might use one or the other are in some ways irrelevant. The fact is, they do. I'm proposing the following:<br />
<blockquote class="tr_bq">
<span style="font-size: large;"><i>"When I.T. staff are given access to a public and a private cloud, they will use both. Either way, they will get their work done faster and ultimately save their employer money in labor and asset costs."</i></span></blockquote>
I had a real hard time swallowing Jason's analysis that clouds are only good when you rent them from a third party like Amazon or Rackspace. Using the vehicle analogy, I believe that it's OK to own your car and to rent other vehicles when needed (e.g., boats, RV's, taxi-cabs, vacation bikes, jet ski's, limos, and so on). It's not an all-or-nothing proposition.<br />
<br />
The one thing I want to leave you with is this: I.T. staff will use both - and they'll figure out when to use each. They're not dumb. They don't blindly listen to bloggers, authors, analysts or tweeters. Give them access and let them do what you pay them to do. Empower them.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-3153693.post-53879845645572290062012-04-04T08:02:00.002-05:002012-04-04T08:02:30.539-05:00Formation of Transcend Computing<br />
<div class="MsoNormal">
I’m excited to announce that today, April 4<sup>th</sup>,
our new company Transcend Computing will be emerging from stealth mode. In
short, we are launching:</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i><u>StackStudio</u> is a visual, drag-and-drop online
development environment for assembling multi-tier application topologies using
the Amazon CloudFormation format. Application stacks assembled with StackStudio
are ready to run on Amazon Web Services (AWS) and on other public and private
ACE platforms. <o:p></o:p></i></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>These stacks can then be shared with other developers in <u>StackPlace</u>,
which was also launched today as an open social architecture community
sponsored by Transcend Computing. StackPlace allows developers to create,
contribute, consume and collaborate on ACE-compatible application topologies. <o:p></o:p></i></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
To learn more, please visit: <a href="http://www.transcendcomputing.com/">http://www.TranscendComputing.com</a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This is an exciting time for the Momentum family. As most of
you know, we’ve been incubating this program for the last couple of years. The
initial offering is a SaaS solution used to create multi-part applications on
AWS. In the coming months, we'll be introducing additional on-premise services. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It's been fun to watch the transition from SOA to 'as-a-Service'. There's little doubt that cloud (IaaS/PaaS) is the new model for application development and deployment. This is one of those few areas where both engineers and executives can agree on a new paradigm. This recipe for success will unfold over the coming years - and we're excited to be leaders in this new movement. </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-9023495703879615812011-12-03T08:08:00.001-05:002011-12-03T09:08:08.834-05:00Will Amazon Support Linux Containers?<span style="font-family: inherit;">Early on, Amazon EC2 was recognized as the leading IaaS provider because of their ability to easily provision new virtual machines with a variety of configurations (size, speed, attachments, etc.) Virtual machines are a powerful, yet simple tool for engineers to use but they come at a price (a performance hit). At <a href="http://www.momentumsi.com/" target="_blank">MomentumSI</a>, we've been pondering if Amazon would ever support Linux Containers in their cloud. </span><br />
<span style="font-family: inherit;"><br /></span><br />
<span style="font-family: inherit;">When asked, "Will Amazon Support Linux Containers?" </span><span style="font-family: inherit;">Raj comments, "</span><i style="font-family: inherit;">Would love it. We may see a type of instance which
allows containers on it. You will have to take the whole machine and not just
a container on it. That way AWS will not have to bother about maintaining the host
OS. Given the complexities I think it will be a lower priority for Amazon and
as it may be financially counterproductive; they may never do it.</i><span style="font-family: inherit;">"</span><br />
<span style="font-family: inherit;"><br /></span><br />
<br />
<div class="MsoPlainText">
</div>
<div class="MsoPlainText">
<span style="font-family: inherit;">Tom comments, "<i>I doubt it. While I'm one of, if not *the*, biggest
proponent of linux containers, the business reasoning still lags the technical
reasoning. Intel, for instance, would *hate* such a move. Why? They spent a ton
of money on virtualization at a chip level, which becomes a non-issue in
containers (no hardware gets shared at the metal, rather, it's all one kernel
for all containers). So, while it would be a great thing to see, the business
market simply doesn't support this at this point, other than for folks like
Pixar or other compute heavy folks.</i></span></div>
<div class="MsoPlainText">
<br /></div>
<div class="MsoPlainText">
<span style="font-family: inherit;"><i>What I *would* bet on is that AWS internally switches to
some container based systems. For instance, ElasticMapReduce is far better off
in a container world than in a VM world. Easier to maintain, direct access to
'cpu speed' and no need to virtualize access to disks -- it's all just there
(even ISCSI ends up better in containers -- no 'vm to hypervisor' network
translations).</i>"</span></div>
<br />
<div class="MsoPlainText">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoPlainText">
</div>
<div class="MsoPlainText">
<span style="font-family: inherit;">Amazon will likely be forced into one of three positions: </span></div>
<div class="MsoPlainText">
<span style="font-family: inherit;">1. Delivering sub-optimal platform performance on VM's (current state)</span></div>
<div class="MsoPlainText">
<span style="font-family: inherit;">2. Supporting Linux Containers behind the scenes but not giving customer access to it. </span></div>
<div class="MsoPlainText">
<span style="font-family: inherit;">3. Delivering Linux Containers to customers and dealing with a whole new set of technical headaches. </span></div>
<div class="MsoPlainText">
<span style="font-family: inherit;"><br /></span></div>
<br />
<div class="MsoPlainText">
<span style="font-family: inherit;">I'm more optimistic than my counterparts on the likelihood of #3. My reasons are simple: First, Amazon has done what they needed to do to satisfy customer needs. Second, I think they'll need to do it to remain competitive with companies like Rackspace. As developers move from "needing a vm" to "needing a platform" (database, app server, etc.), Amazon will be pressed to expose a more highly performant layer to platform developers. One thing my associates and I agreed on is that we will not likely see containers in 2012... perhaps 2013?</span></div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3153693.post-51219680416520381932011-11-22T19:03:00.001-05:002011-11-22T19:38:28.379-05:00Is Cloud Foundry a PaaS?I've been asking some people in the industry a real simple question, "Is Cloud Foundry a Platform as a Service"?<br />
<br />
The obvious answer would seem to be "yes" - after all, VMware told us it's a PaaS:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-j4M7sfWnUzc/Tsw5HLMdngI/AAAAAAAAAIU/zvoMRfZU9Hs/s1600/cloudfoundry.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="75" src="http://2.bp.blogspot.com/-j4M7sfWnUzc/Tsw5HLMdngI/AAAAAAAAAIU/zvoMRfZU9Hs/s640/cloudfoundry.PNG" width="640" /></a></div>
<br />
That should be the end of it, right? For some reason, when I hear "as-a-Service", I expect a "service" - as in <b><span style="font-size: large;">Service Oriented</span></b>. I don't think that's too much to ask. For example, when Amazon released their relational data service, they offered me a published service interface:<br />
<a href="https://rds.amazonaws.com/doc/2010-07-28/AmazonRDSv4.wsdl" target="_blank">https://rds.amazonaws.com/doc/2010-07-28/AmazonRDSv4.wsdl</a>
<br />
<br />
I know there are people who hate SOAP, WS-*, WSDL, etc. - that's cool, to each their own. If you prefer, use the RESTful API: <a href="http://docs.amazonwebservices.com/AmazonRDS/latest/APIReference/" target="_blank">http://docs.amazonwebservices.com/AmazonRDS/latest/APIReference/</a><br />
<br />
Note that the service interface IS NOT the same as the interface of the underlying component (MySQL, Oracle, etc.), as those are exposed separately.<br />
<br />
Back to my question - is Cloud Foundry a PaaS?<br />
<br />
If so, can someone point me to the WSDL's, RESTful interfaces, etc?<br />
<br />
Will those interfaces be submitted to DMTF, OASIS or another standards body?<br />
<br />
Alternatively, is it merely a platform substrate that ties together multiple server-side technologies (similar to JBoss or WebSphere)?Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3153693.post-69083257191816376292011-11-22T08:45:00.001-05:002011-11-22T09:25:28.813-05:00Will cultural pushback kill private clouds?Derick Harris asks the question, "<a href="http://gigaom.com/cloud/will-cultural-pushback-kill-private-clouds/" target="_blank">Will cultural pushback kill private clouds?</a>" His questioning comes from a piece provided by <a href="http://cloudpundit.com/2011/11/18/to-become-like-a-cloud-provider-fire-everyone-here/" target="_blank">Lydia Leong</a> where she notes that many enterprises have fat management structures and aren't organized like many of the leaner cloud providers.<br />
<br />
I tend to agree with the premise that the enterprise will have difficulties in adopting private cloud but not for the reasons the authors noted. The IaaS & PaaS software is available. Vendors are now offering to manage your private cloud in an outsourced manner. More often than not, companies are educated on cloud and "get it". They have one group of people who create, extend and support the cloud(s). They have another group who use it to create business solutions. It's a simple consumer & provider relationship.<br />
<br />
Traditionally, there are three ways things get done in Enteprise IT:<br />
1. The CIO says "get'er done" (and writes a check)<br />
2. A smart business/IT person uses program funds to sneak in a new technology (and shows success)<br />
3. Geeks on the floor just go and do it.<br />
<br />
With the number of downloads of open source stacks like OpenStack and Eucalyptus, it is apparent that model #3 is getting some traction. My gut tells me that the #2 guys are just pushing their stuff to the public cloud (will beg forgiveness - not asking for permission). On #1, many CIO's are hopeful that they can just 'extend their VMware' play - while more aggressive CIO's are looking to the next generation cloud vendors to provide something that matches the public cloud features in a more direct manner.<br />
<br />
There are adoption issues in the enterprise. However, it's the same old reasons. Fat org-charts aren't going away and will not be the life or death of private cloud. In my opinion, we need the CIO's to make bold statements on switching to an internal/external cloud operating model. Transformation isn't easy. And telling the CIO that they need to fire a bunch of managers in order to look more like a cloud provider is silly advice and a complete non-starter.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-10053642005650323782011-08-12T07:06:00.003-05:002011-08-12T08:12:57.817-05:00Measuring Availability of Cloud Systems<span class="Apple-style-span" >The analysts at Saugatuck Technology recently wrote a note on "Cloud IT Failures Emphasize Need for Expectation Management". One comment caught my attention:</span><div><em><span class="Apple-style-span" >
<br /></span></em></div><div><em><span class="Apple-style-span" ></span></em><blockquote><span class="Apple-style-span" ><em>"Recall that the availability of a group of components is the product of all of the individual component availabilities.</em> For example, the overall availability of 5 components, each with 99 percent availability, is: 0.99 X 0.99 X 0.99 X 0.99 X 0.99 = 95 percent."</span></blockquote><span class="Apple-style-span" ></span></div><div><span class="Apple-style-span" >
<br /></span></div><div><span class="Apple-style-span" >I understand their math - but it strikes me odd that they would use this thinking when discussing cloud computing. In cloud environments, the components are often available as virtualized n+1 highly available pairs. If one is down, the other is taking over. In a non-cloud world, this architecture is typically only reserved for the most critical components (e.g., load balancers or other single-point-of-failures). It's also common to create a complete replica of the environment in a disaster recovery area (e.g., AWS availability zones). In theory, this leads to very high up-time. </span></div><div><span class="Apple-style-span" >
<br /></span></div><div><span class="Apple-style-span" >Let me put this another way... I currently have 2 cars in my driveway. Let's say each of them has 99% up-time. If one car doesn't start, I'll try the other car. If neither car starts, I'll most likely walk over to my neighbors house and ask to borrow one of their two cars (my DR plan). You can picture the math... in the 1% chance that car A fails, theirs a 99% chance that car B will succeed, and so on. However, experience in both cars and in computing tells us that this math doesn't work either. For instance, if car A didn't start because it was 20 degrees below zero outside, there's a good chance that car B won't work start - and for that matter, my neighbors cars won't start either. Structural or natural problems tend to infect the mass. </span></div><div><span class="Apple-style-span" >
<br /></span></div><div><span class="Apple-style-span" >I wish I could show you the new math for calculating availability in cloud systems - but it's beyond my pay grade. What I know is that the old math isn't accurate. Anyone have suggestions on a more modern approach?</span></div><div><span style="font-size:10.0pt;font-family: "Arial","sans-serif";mso-fareast-font-family:Calibri;mso-fareast-theme-font: minor-latin;mso-ansi-language:EN-US;mso-fareast-language:EN-US;mso-bidi-language: AR-SA"></span></div>Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-3153693.post-14705708414008507962011-08-11T07:16:00.002-05:002011-08-11T07:49:12.841-05:00OpenShift: Is it really PaaS?Redhat recently announced an upgraded version of OpenShift with exciting new features including support for Java EE6, Membase, MongoDB and more. See details at: <div><a href="https://www.redhat.com/openshift/blogs/whats-new-in-openshift-august-2011">https://www.redhat.com/openshift/blogs/whats-new-in-openshift-august-2011</a></div><div>
<br /></div><div>As I dug through the descriptions, I found myself with more questions than answers. When you say Membase or MongoDB are available as part of the PaaS, what does this really mean? For example:</div><div><ul><li>They're pre-installed in clustered or replicated manner?</li><li>They're monitored out of the box?</li><li>Will it auto-scale based on the monitoring data and predefined thresholds? (both up and down?)</li><li>They have a data backup / restore facility as part of the as-a-service offering?</li><li>The backup / restore are as-a-service?</li><li>The backup / restore use a job scheduling system that's available as-a-service?</li><li>The backup / restore use an object storage system that has cross data center replication?</li></ul></div><div>Ok, you get the idea. Let me be clear - I'm not suggesting that OpenShift does or doesn't do these things. Arguments can be made that it in some cases, it doesn't need to do them. My point is that several new "PaaS offerings" are coming to market and they smell like the same-ole-sh!t. If nothing else, the product marketing teams will need to do a better job of explaining what they currently have. Old architects need details. </div><div>
<br /></div><div>It's no secret that I'm a fan of Amazon's approach of releasing their full API's (AWS Query, WSDL, Java & Ruby API's, etc.) along with some great documentation. They've built a layered architecture whereby the upper layers (PaaS) leverage lower layers (Automation & IaaS) to do things like monitoring, deployment & configuration of both the platforms and the infrastructure elements (block storage, virtual compute, etc.) The bar has been set for what makes something PaaS - and going forward, products will be measure based on this basis. It's ok if your offering doesn't do all they sophisticated things you find in AWS - but it's better to be up front about it. Old architects will understand. </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-84237077700815353312011-04-26T06:06:00.003-05:002011-04-26T06:37:44.767-05:00Private Cloud Provisioning Templates<div><div>One of the primary benefits of a cloud computing environment is the increased automation. The <a href="http://www.momentumsi.com/solutions/iaas-extensions/">Provisioning Service</a> is perhaps the core mechanism to deliver this. To better understand the kinds of things we might orchestrate, take a look at the following template. You'll notice that it takes on the same format as Amazon's CloudFormation. This example launches a load balancer as part of our LB-aaS solution for a Eucalyptus cloud:</div><div><br /></div><div>{</div><div> "ToughTemplateFormatVersion" : "2011-03-01",</div><div><br /></div><div> "Description" : "Launch Load Balancer instance and install LB software.",</div><div><br /></div><div> "Parameters" : {</div><div> "AvailabilityZone" : {</div><div> "Description" : "AvaialbilityZone in which an instance should be created",</div><div> "Type" : "String"</div><div> },</div><div> "AccountId" : {</div><div> "Description" : "Account Id",</div><div> "Type" : "String"</div><div> },</div><div> "LoadBalancerName" : {</div><div> "Description" : "Load Balancer Name",</div><div> "Type" : "String"</div><div> }</div><div> },</div><div><br /></div><div> "Mappings" : {</div><div> "AvailabilityZoneMap" : {</div><div> "msicluster" : {</div><div> "SecurityGroups" : "default",</div><div> "ImageId" : "emi-FF070BFE",</div><div> "KeyName" : "rarora",</div><div> "EKI" : "eki-3A4A0D5A",</div><div> "ERI" : "eri-B2C7101A",</div><div> "InstanceType" : "c1.medium",</div><div> "UserData" : "80"</div><div> }</div><div> }</div><div> },</div><div><br /></div><div> "Resources" : {</div><div> "LoadBalancerLaunchConfig": {</div><div> "Type": "TOUGH::LaunchConfiguration",</div><div> "Properties": {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span>"AccountId" : { "Ref" : "AccountId" },</div><div> "SecurityGroups" : { "Fn::FindInMap" : [ "AvailabilityZoneMap", { "Ref" : "AvailabilityZone" }, "SecurityGroups" ]},</div><div> "ImageId" : { "Fn::FindInMap" : [ "AvailabilityZoneMap", { "Ref" : "AvailabilityZone" }, "ImageId" ]},</div><div> "KeyName" : { "Fn::FindInMap" : [ "AvailabilityZoneMap", { "Ref" : "AvailabilityZone" }, "KeyName" ]},</div><div> "InstanceType" : { "Fn::FindInMap" : [ "AvailabilityZoneMap", { "Ref" : "AvailabilityZone" }, "InstanceType" ]},</div><div> "EKI" : { "Fn::FindInMap" : [ "AvailabilityZoneMap", { "Ref" : "AvailabilityZone" }, "EKI" ]},</div><div> "ERI" : { "Fn::FindInMap" : [ "AvailabilityZoneMap", { "Ref" : "AvailabilityZone" }, "ERI" ]}</div><div> }</div><div> },</div><div> </div><div> "LoadBalancerInstance" : {</div><div> "Type" : "TOUGH::EUCA::LaunchInstance",</div><div> "Properties" : {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span>"AccountId" : { "Ref" : "AccountId" },</div><div> "AvailabilityZone": { "Ref" : "AvailabilityZone" },</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>"LaunchConfig" : { "Ref" : "LoadBalancerLaunchConfig" },</div><div> "Setup" : {</div><div> }</div><div> }</div><div> },</div><div> </div><div> "RegisterLoadBalancerInstance" : {</div><div> "Type" : "TOUGH::ElasticLoadBalancing::RegisterLoadBalancerInstance",</div><div> "Properties" : {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span>"AccountId" : { "Ref" : "AccountId" },</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span>"LoadBalancerName" : { "Ref" : "LoadBalancerName" },</div><div> "Instance" : { "Ref" : "LoadBalancerInstance" }</div><div> }</div><div> },</div><div> </div><div> "Setup" :{</div><div> "Type" : "TOUGH::EUCA::Parallel",</div><div> "Operations" : {</div><div> "TrackLoadBalancerInstance" : {</div><div> "Type" : "TOUGH::EUCA::TrackInstance",</div><div> "Name" : "LoadBalancerInstance",</div><div> "Properties" : {</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span> "AccountId" : { "Ref" : "AccountId" },</div><div> "InstanceId" : { "Fn::GetAtt" : [ "LoadBalancerInstance", "InstanceId" ] }</div><div> }</div><div> },</div><div> "InstalLoadBalancerSoftware" : {</div><div> "Type" : "TOUGH::ElasticLoadBalancing::InstallLoadBalancerSoftware",</div><div> "Properties" : {</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span> "AccountId" : { "Ref" : "AccountId" },</div><div> "IP" : { "Fn::GetAtt" : [ "LoadBalancerInstance", "PublicIp" ] }</div><div> }</div><div> }</div><div> }</div><div> }</div><div> },</div><div><br /></div><div> "Outputs" : {</div><div> "PublicIP" : {</div><div> "Description" : "PublicIP address of the LoadBalancer",</div><div> "Value" : { "Fn::GetAtt" : [ "LoadBalancerInstance", "PublicIp" ] }</div><div> }</div><div> }</div><div>}</div></div><div><br /></div><div>The JSON format can be a bit difficult to read if you're not familiar with it. Amazon and others now have UI's that facilitate the creation of the templates. In this example, there are a few items worth noting:</div><div>1. The template accepts input variables and returns information at the end of execution</div><div>2. The orchestration automates a series of tasks (launches a bare image, installs LB software, tracks the progress, configures the software, registers the newly launched instance, etc.)</div><div>3. The templates treat the cloud concepts (availability zones, cloud services, etc.) as first-order concepts in the syntax. </div><div><br /></div><div>Keep in mind that the orchestration scripts can be multiple levels deep. This example was a simple one just to launch a load balancer. A more complicated orchestration would initiate multiple orchestration templates. </div><div><br /></div><div>In the coming months, we'll be releasing a series of templates designed to orchestrate the provisioning of many common applications. The provisioning templates will fully leverage the power of the cloud (auto scale, auto recover, auto-snapshot, auto balance, etc.)</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-85131087612233442532011-04-24T07:28:00.007-05:002011-04-25T07:41:37.874-05:00Private Cloud Provisioning & ConfigurationCloud provisioning has focused on the rapid acquisition and initialization of a new server, disk or some other piece of infrastructure. Provisioning a single piece of infrastructure is now quite easy. Provisioning an entire set is much more complicated. In addition to the setup of a single piece of equipment, it's necessary to understand the dependencies between elements. In some cases, certain infrastructure components must be launched before another element or configuration data from one item needs to be used in a third element. Getting it all right is a difficult task and is a major cause of system failures. An approach to solving the problem is to consider the <b>Deployment Fidelity, </b>that is, the degree to which a deployment is able to fully describe it's architecture and configuration in a digitally precise manner. <div><br /></div><div>Historically, application architects have used Word documents and Visio diagrams to depict the relationship between their software modules and the hardware infrastructure that would host them. Deployment Fidelity deals with accurately describing a set of computing resources and their relationship to each other. Organizations that embrace high fidelity will digitally describe their software and hardware topology: what type of hardware, operating systems, memory, infrastructure services, platform services, etc. and pass the digital description to the cloud provisioner for execution. The business value is two-fold. First, the high fidelity description reduces the chances of manual error, especially during hand-off. Second, the automation of the provisioning task reduces the deployment time and associated costs (e.g., sysadmins running individual scripts, testers waiting for new environments, etc.)</div><div><br /></div><br /><br /><a href="http://www.momentumsi.com/wp-content/uploads/2011/04/Provisioning.png" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 493px; height: 309px;" src="http://www.momentumsi.com/wp-content/uploads/2011/04/Provisioning.png" border="0" alt="" /></a><br /><br /><div>To increase the Deployment Fidelity, the relationships between elements must be captured. For instance, if an application server uses a relational database, the link between the two is recorded and configuration variables (such as IP addresses) are noted. If the server has an outage, a replacement can be auto-launched with the same configuration information. As the complexity of an application increases (load balancers, web servers, app servers, multiple databases, message queues, pub/sub, etc.) the need to keep a digital description becomes extremely important in order to reduce the chance of errors during deployment. </div><div><br /></div><div>From an organizational perspective, there are two highlights: 1. The deployment architect can describe their proposed solution with complete fidelity - no misinterpretation. In addition, if there is an issue, the changes to the architecture can be captured in version control, just as if it was another piece of software code. 2. The sysadmin or release engineer can take the provisioning script and easily create a new environment (i.e., replicating Dev to Test, etc.)</div><div><br /></div><div>Today, MomentumSI is announcing the release of two new services that orchestrate the provisioning of complex application topologies and then provide the configuration information:</div><div><b>The Tough Provisioning Service provides equivalent functionality found in Amazon's CloudFormation and is API/Syntax compatible with their offering.</b> </div><div><br /></div><div><b>The Tough Configuration Service integrates the most popular configuration management systems into the private cloud.</b> Use your choice of Chef or Puppet to create configuration scripts and then expose them as enterprise grade services (secure access, multiple node delivery, guaranteed transmission, closed loop feedback, etc.)</div><div><br /></div><div>Our solution brings this functionality to your private cloud by complementing your existing investment in VMware or Eucalyptus. </div><div><br /></div><div>For more information, see <a href="http://www.momentumsi.com/solutions/iaas-extensions/">Tough Solutions</a>.</div><div> </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-32414509912526714032011-04-05T06:06:00.002-05:002011-04-05T06:24:23.884-05:00Are Enterprise Architects Intimidated by the Cloud?Are Enterprise Architects Intimidated by the Cloud? <div><br /></div><div>EA's are often the champion of large change initiatives that span multiple business units. If they're not on board - we've got problems. </div><div><br /></div><div>Here's why I ask the question:</div><div>1. It's my perception (perhaps incorrect) that the EA leadership typically doesn't come from a background in infrastructure architecture. It's been my observation that the EA's who tend to get promoted usually have a background in business or application architecture. These people are often hesitant to enter deep discussions on CPU power consumption, DNS propagation, VLAN decisions, storage protocols, hypervisor trade-offs, etc. </div><div><br /></div><div>2. Most people have agreed that the cloud can be viewed as a series of layers. You can attack it from top (SaaS) or bottom (IaaS). Quite frankly, there isn't *that much* architecture in SaaS (other than the secure connection and integration). That leaves IaaS as the starting point - which takes me back to point #1 - IaaS intimidates the EA team - - meaning that they're relying on the I.T. data center operations team (and localized infrastructure architects) to define the foundational IaaS layers which will serve PaaS, Dev/Test, disaster recovery, hadoop clusters, etc. </div><div><br /></div><div>Any truth here? Leave a comment (moderated) or send me an email either way: jschneider AT MomentumSI DOT com</div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3153693.post-61377953091043969122011-04-04T05:37:00.002-05:002011-04-04T05:56:11.136-05:00Cloud.com offers Amazon API<div><span class="Apple-style-span" style="color: rgb(73, 73, 73); line-height: 14px; "><span class="Apple-style-span" >The most recent version of Cloud.com is now offering a 'bridge' for the core AWS EC2 services:</span></span></div><div><span class="Apple-style-span" style="color: rgb(73, 73, 73); line-height: 14px; "><span class="Apple-style-span" ></span></span></div><blockquote><div><span class="Apple-style-span" style="color: rgb(73, 73, 73); line-height: 14px; "><span class="Apple-style-span" ><br /></span></span></div><div><span class="Apple-style-span" style="color: rgb(73, 73, 73); line-height: 14px; "><span class="Apple-style-span" >"CloudBridge provides a compatibility layer for CloudStack cloud computing software that tools designed for Amazon Web Services with CloudStack.<br /><br />The CloudBridge is a server process that runs as an adjunct to the CloudStack. The CloudBridge provides an Amazon EC2 compatible API via both SOAP and REST web services."</span></span></div></blockquote><div><span class="Apple-style-span" style="color: rgb(73, 73, 73); line-height: 14px; "><span class="Apple-style-span" ></span></span></div><div><span class="Apple-style-span" >The functions they support include:</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Addresses</span></b></div><div><span class="Apple-style-span" >AllocateAddress</span></div><div><span class="Apple-style-span" >AssociateAddress</span></div><div><span class="Apple-style-span" >DescribeAddresses</span></div><div><span class="Apple-style-span" >DisassociateAddress</span></div><div><span class="Apple-style-span" >ReleaseAddress</span></div><div><span class="Apple-style-span" >Availability Zones</span></div><div><span class="Apple-style-span" >DescribeAvailabilityZones</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Images</span></b></div><div><span class="Apple-style-span" >CreateImage</span></div><div><span class="Apple-style-span" >DeregisterImage</span></div><div><span class="Apple-style-span" >DescribeImages</span></div><div><span class="Apple-style-span" >RegisterImage</span></div><div><span class="Apple-style-span" >Image Attributes</span></div><div><span class="Apple-style-span" >DescribeImageAttribute</span></div><div><span class="Apple-style-span" >ModifyImageAttribute</span></div><div><span class="Apple-style-span" >ResetImageAttribute</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Instances</span></b></div><div><span class="Apple-style-span" >DescribeInstances</span></div><div><span class="Apple-style-span" >RunInstances</span></div><div><span class="Apple-style-span" >RebootInstances</span></div><div><span class="Apple-style-span" >StartInstances</span></div><div><span class="Apple-style-span" >StopInstances</span></div><div><span class="Apple-style-span" >TerminateInstances</span></div><div><span class="Apple-style-span" >Instance Attributes</span></div><div><span class="Apple-style-span" >DescribeInstanceAttribute</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Keypairs</span></b></div><div><span class="Apple-style-span" >CreateKeyPair</span></div><div><span class="Apple-style-span" >DeleteKeyPair</span></div><div><span class="Apple-style-span" >DescribeKeyPairs</span></div><div><span class="Apple-style-span" >ImportKeyPair</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Passwords</span></b></div><div><span class="Apple-style-span" >GetPasswordData</span></div><div><span class="Apple-style-span" >Security Groups</span></div><div><span class="Apple-style-span" >AuthorizeSecurityGroupIngress</span></div><div><span class="Apple-style-span" >CreateSecurityGroup</span></div><div><span class="Apple-style-span" >DeleteSecurityGroup</span></div><div><span class="Apple-style-span" >DescribeSecurityGroups</span></div><div><span class="Apple-style-span" >RevokeSecurityGroupIngress</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Snapshots</span></b></div><div><span class="Apple-style-span" >CreateSnapshot</span></div><div><span class="Apple-style-span" >DeleteSnapshot</span></div><div><span class="Apple-style-span" >DescribeSnapshots</span></div><div><span class="Apple-style-span" ><br /></span></div><div><b><span class="Apple-style-span" >Volumes</span></b></div><div><span class="Apple-style-span" >AttachVolume</span></div><div><span class="Apple-style-span" >CreateVolume</span></div><div><span class="Apple-style-span" >DeleteVolume</span></div><div><span class="Apple-style-span" >DescribeVolumes</span></div><div><span class="Apple-style-span" >DetachVolume</span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >Although this list represents the core features of EC2, it doesn't yet cover the upper layers (CloudWatch, Auto Scale, etc.) or the PaaS offering (SNS, SQS, etc.) Regardless, I'm excited to see more emphasis being placed on supporting the AWS standard. It's easy for people to say that IaaS standards don't matter. However, if you're the guy building software on top of IaaS, they matter a WHOLE lot. </span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >Cloud.com is a solid piece of software that has achieved success in the service provider market. To date, they haven't pushed too hard in the enterprise. Their decision to embrace the AWS API is a good one - and is complemented with their decision to use the pieces of OpenStack in their software where appropriate. This idea seems to be getting more traction. I'm hearing more and more people talking about OpenStack like it's a drawer that you reach into and grab out the components that you want - - rather than a holistic platform. I'm not sure if that's what the OpenStack team was shooting for but it's interesting to see guys like Cloud.com being open to leveraging the bits and pieces that they find useful. </span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" ><br /></span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-54625228327487506212011-04-02T07:48:00.002-05:002011-04-02T08:28:36.128-05:00The commoditization of scalabilityLast week, I had an interesting discussion with a product owner at an ISV. We discussed his offering; it was core plumbing-middleware-kind-of-stuff. When I asked about how he differentiated his offering from others on the market the answer was that <b>they scale better</b>. Our discussion moved from what he was doing to what I was up to and without trying to be coy I said, <b>"We enable the commoditization of scalability"</b>. What I mean by this is that we help our customers adopt public and private clouds that know how to auto scale applications (and much more). <div><br /></div><div>Of course, ISV's have always used non-functional attributes like availability, scalability and security as competitive differentiators in their offering. These capabilities are now being provided as features in the IaaS fabric. The next generation products coming from ISV's will need to redesign their solution on top of cloud infrastructures like Amazon, Eucalyptus, vCloud Director, Cloud.com, OpenStack and Nimbula. It will no longer be acceptable for an ISV to march into a customer and demand a block of servers to run their proprietary clusters. They will be expected to be able to allocate computer resources from the IaaS common pool. In addition, the ISV's will need to differentiate on attributes other than those provided by the IaaS fabric. </div><div><br /></div><div>This change will affect the corporate I.T software development department as well. I've witnessed several I.T. groups design highly scalable architectures. Usually, the I.T. personnel aren't educated to perform this kind of work and either the project fails or delivery costs are very high. I believe that the I.T. departments that invest in IaaS will be able to significantly reduce the cost to design, deploy and operate highly scalable systems. It might be premature to declare the commoditization of scalability, but I truly believe we are witnessing the most significant step towards that goal in my 20 year career.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-32110433089384304272011-03-16T03:33:00.007-05:002011-03-16T08:05:05.051-05:00Providing Cloud Service Tiers<p class="MsoPlainText">In the early days of cloud computing emphasis was placed on 'one size fits all'. However, as our delivery capabilities have increased, we're now able to deliver more product variations where some products provide the same function (e.g., storage) but deliver better performance, availability, recovery, etc. and are priced higher. I.T. must assume that some applications are business critical while others are not. Forcing users to pay for the same class of service across the spectrum is not a viable option. We've spent a good deal of time analyzing various cloud configurations, and can now<b> deliver tiered classes of services in our private clouds. </b></p><p class="MsoPlainText">Reviewing trials, tribulations and successes in implementing cloud solutions, one can separate tiers of cloud services into two categories: 1) higher throughput elastic networking; or 2) higher throughput storage. We leave the third (more CPU) out of this discussion because it generally boils down to 'more machines,' whereas storage and networking span all machines.</p> <p class="MsoPlainText">Higher network throughput raises complex issues regarding how one structures networks <span style="mso-bidi-font-family:Consolas">– VLAN or L2 isolation, shared segments and others. Those complexities, and related costs, increase dramatically when adding multiple speed NICS a</span>nd switches, for instance 10GBase-T, NIC teaming and other such facilities. We will delve into all of that in a future post.</p><p class="MsoPlainText"><b>Tiered Storage on Private Cloud</b></p> <p class="MsoPlainText">Where tiered storage classes are at issue, cost and complexity is not such a dramatic barrier, unless we include a mix of network and storage (i.e., iSCSI storage tiers). For the sake of simplicity in discussion, let's ignore that and break the areas of tiered interest into: 1) elastic block storage (<span style="mso-bidi-font-family:Consolas">“EBS”); 2) cached virtual machine images; 3) running virtual machine (“VM”</span>) images. In the MomentumSI private cloud, we've implemented multiple tiers of storage services by <b>adding solid state drives (SSD)</b> drives to each of these areas, but doing so requires matching the nature of the storage usage with the location of the physical drives.</p> <p class="MsoPlainText">Consider implementing EBS via higher speed SSD drives. Because EBS volumes avail themselves over network channels to remain attachable to various VMs, unless very high speed networks carry the drive signaling and data, a lower speed network would likely not allow dramatic speed improvements normally associated with SSD. Whether one uses ATA over Ethernet (AoE), iSCSI, NFS, or other models to project storage across the VM fabric, even standard SATA II drives, under load could overload a one-gigabit Ethernet segment. However, by <b>exposing EBS volumes on their own 10Gbe network segments</b>, EBS traffic stands a much better chance of not overloading the network. For instance, at MSI we create a second tier of EBS service by mounting SSD on the mount points under which volumes will exist <span style="mso-bidi-font-family: Consolas">– e.</span>g., /var/lib/eucalyptus/volumes, by default, on a Eucalyptus storage controller. Doing so gives users of EBS volumes the option of paying more for 'faster drives.'</p> <p class="MsoPlainText">While EBS gives users of cloud storage a higher tier of user storage, the cloud operations also represent a point of optimization, thus tiered service. The goal is to optimize the creation of images, and to spin them up faster. Two particular operations extract significant disk activity in cloud implementation. First, caching VM images on hypervisor mount points. Consider Eucalyptus, which stores copies of kernels, ramdisks (initrd), and Eucalyptus Machine Images (<span style="mso-bidi-font-family:Consolas">“EMI”) files on a (usually) local drive at the Node Controllers (“NC”). One could also store EMIs on an iSCSI, AoE or NFS, but the sam</span>e discussion as that regarding EBS applies (apply fast networking with fast drives). The key to the EMI cache is not so much about fast storage (writes), rather rapid reads. For each running instance of an EMI (i.e., a VM), the NC creates a copy of the cached EMI, and uses that copy for spinning up the VM. Therefore, what we desire is very fast reads from the EMI cache, with very fast writes to the running EMI store. Clearly that does not happen if the same drive spindle and head carry both operations.</p> <p class="MsoPlainText">In our labs, we use two drives to support the higher speed cloud tier operations: one for the cache and one for the running VM store. However, to get a Eucalyptus NC, for instance, to use those drives in the most optimal fashion, we must direct the reads and writes to different disks,<span style="mso-bidi-font-family:Consolas">– one drive (disk1) dedicated to cache, and one drive (disk2) dedicated to writing/running VM images. Continuing with Eucalyptus as the example setup (though other cloud controllers show similar traits), the NC will, by def</span>ault, store the EMI cache and VM images on the same drive -- precisely what we don't want for higher tiers of services.</p> <p class="MsoPlainText">By default, Eucalyptus NCs store running VMs on the mount point /usr/local/eucalyptus/???, where ??? represents a cloud user name. The NC also stores cached EMI files on /usr/local/eucalyptus/eucalyptus/cache -<span style="mso-bidi-font-family:Consolas">– clearly within the same directory tree. Therefore, unless one mounts another drive (partition, AoE or iSCSI drive, etc.) on /usr/local/eucalyptus/eucalyptus/cache, the </span>NC will create all running images by copying from the EMI cache to the run-space area (/usr/local/eucalyptus/???) on the same drive. That causes significant delays in creating and spinning up VMs. The simple solution: mount one SSD drive on /usr/local/eucalyptus, and then mount a second SSD drive on /usr/local/eucalyptus/eucalyptus/cache. A cluster of Eucalyptus NCs could share the entire SSD 'cache' drive by exposing it as an NFS mount that all NCs<span style="mso-spacerun:yes"> </span>mount at /usr/local/eucalyptus/eucalyptus/cache. Consider that the cloud may write an EMI to the cache, due to a request to start a new VM on one node controller, yet another NC might attempt to read that EMI before the cached write completes, due to a second request to spin up that EMI (not an uncommon scenario). There exist a number of ways to solve that problem.</p> <p class="MsoPlainText">The gist here: by placing SSD drives at strategic points in a cloud, we can create two forms of higher tiered storage services: 1) higher speed EBS volumes; and 2) faster spin-up time. Both create valid billing points, and both can exist together, or separately in different hypervisor clusters. This capability is now available via our <a href="http://www.momentumsi.com/wp-content/uploads/2010/11/Cloud-QuickStart-Eucalyptus-Datasheet.pdf">Eucalyptus Consulting Services</a> and will soon be available for vCloud Director. </p> <p class="MsoPlainText">Next up <span style="mso-bidi-font-family:Consolas">– VLAN, L2, and others for tiered network services.</span></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3153693.post-2600304862115968472011-03-14T03:47:00.003-05:002011-03-14T04:41:24.104-05:00Auto Scaling as a Service<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/-MZd_0l2d9Y8/TX3W7_cAzaI/AAAAAAAAAGM/5qZyzfcqlcs/s1600/Tough-Auto-Scaling-675.png"><span class="Apple-style-span" ><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 400px; height: 242px;" src="http://3.bp.blogspot.com/-MZd_0l2d9Y8/TX3W7_cAzaI/AAAAAAAAAGM/5qZyzfcqlcs/s400/Tough-Auto-Scaling-675.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5583855439138835874" /></span></a><div><span class="Apple-style-span" >The <a href="http://www.momentumsi.com/solutions/iaas-extensions/#toughauto">Tough Auto Scaling Service</a> is our offering to enable the automated scaling of an application tier at runtime. System data collected by a monitoring service provides the intelligence to provision or deprovision resources according to SLA's. Out of the box, our service uses our own <a href="http://www.momentumsi.com/solutions/iaas-extensions/#toughcloud">Tough Monitoring Service</a>, however, since we're using the de facto standard (Amazon Web Services), you can plug in any implementation that is AWS compatible. </span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >The auto scaling service works by defining an 'auto scaling group'. This identifies the kind of service which will shrink or expand based on system load. The most common use case for auto scaling is for the Web tier where additional Web servers are added on the fly to respond to heavy loads. Auto scaling can also be used on stateful tiers but extra attention must be spent on managing the state replication mechanisms (clustering, etc.) </span></div><div><span class="Apple-style-span" ><br /></span></div><div><span class="Apple-style-span" >As new servers are provisioned to respond to the load request, they can be added to a dynamically programmable load balancer. This enables in-bound application traffic to be evenly divided across the array of virtual servers identified in an auto scaling group. Conversely, when the load returns to normal levels, the virtual servers are taken out of the load balanced pool allowing a graceful shutdown. To enable this scenario, we're using our <a href="http://www.momentumsi.com/solutions/iaas-extensions/#toughload">Tough Load Balancing Service</a>, but once again, customers can use any AWS compatible load balancer to perform this operation. </span></div><div><br /></div><div>One of the key concepts of cloud computing is the concept of 'elasticity'; another is 'automation'. The Auto Scaling Service brings these two concepts together and applies them toward the compute side of the world to provide three key benefits:</div><div>1. Increased success rates on Service Level Agreements - The system auto scales to meet SLA's</div><div>2. Higher utilization rates - Unused virtual servers are released back to the pool</div><div>3. Reduced operating costs - Predefined policies automate activities that previously would have been human intensive tasks. </div><div><br /></div><div>Combined, these three benefits make auto scaling a critical component of any private / hybrid cloud environment. It's also worth pointing out that the auto scaling service is a fundamental building block to enable other scalable services such as Platform Services (PaaS). </div>Unknownnoreply@blogger.com0