Tag Archives: devops

Content & Applications, Devops World 2015, Interviews, Ticketmaster

Ticketmaster VP of Engineering talks DevOps

Stephen Williams VP Engineering TicketmasterIs there anything that Stephen Williams, VP Engineering at Ticketmaster can’t do? Whether it be leading the technology and development of the International Ticketmaster and Live Nation consumer platforms for the last 10 years or building web and apps across a heterogeneous range of technologies that include the best of breed OSS and commercial software founded on Java, PHP and .Net stacks. There is no doubt that he will be a great addition to the speaker line up and the upcoming DevOps World event on November 4th in London.

Over the last 2 years Steve has been focusing attention across all international teams to define and direct the change and implementation of co-ordinated engineering strategies in collaboration with Product and Technical Operations teams. A primary focus has been the evangelising and embracing DevOps culture: Steve led defining the aspects of Ticketmaster DevOps program, the development of a unique way to visualise the program of work and the journey they’re now on. Prior to the event Stephen shared some views on DevOps and a few other things besides.

What does your role involve and how are you involved with DevOps?

My role involves overseeing the management of two teams, in London and Sweden, working on the Ticketmaster International and Live Nation consumer platforms both supporting in 10-15 markets and growing. I’m very fortunate in having two great managers on both platforms, which enables me to also focus on larger strategic projects across our entire international engineering organisation.

I’ve been very involved with DevOps from the start within Ticketmaster International. Myself and another colleague together defined the International TM DevOps strategy. Following the release of the strategy we set up focused working groups to create some essential standards around tooling and instrumentation. From there we worked with various teams to convert the strategy into requirements and enable all teams to begin their journey. At the same time defined KPIs show where DevOps is having positive impacts and allow us to report this back to the business to promote the benefits, or if benefits are not being realised as expected then we can re-evaluate the strategies.

How have you seen DevOps affecting IT teams’ work?

Our TM DevOps Strategy has provided goals and a shared vision for our Teams. The strategy is defined in a way that allows each team to select their own path, which they select depending on the context of their needs. If you think of a roadmap, there are many ways to get from Point A to Point B – you the driver will determine which is the most appropriate route depending on various factors. Our strategy works in a similar way.

Having the right vision and ability to choose your path has created motivation and desire to succeed across our teams. It’s inspiring them to want to deploy faster and create opportunities for the business to learn quicker about new features. Having standards for tooling and best practices is helping to create a culture where more collaboration and sharing of ideas is starting to happen so we only solve problems the one time.

What is the biggest challenge you are facing with DevOps and how are you trying to overcome it?

The biggest challenges is capacity within the systems engineering team to align closer to the product delivery teams, whilst still having a large operational support requirements to service. It can be a slow process to unpick some areas and re-align teams when so many demands are coming in. There are several initiatives we’re employing such as shift left, moving operational tasks to support teams and free some capacity for the Systems Engineers to work more closely with developers. A lightweight CAB and improving demand management filtering have also been put in place to funnel requests.

Can you share a book, article, movie that you recently read/watched and inspired you?

I’m currently working on an organisational strategy to implement competency based skills frameworks to standardise the roles across the international engineering organisation, increase operational efficiency and support career progression and the satisfaction of staff. Research to develop the strategy led me to several articles and videos on Holacracy. Holacracy is attempting to define a way an organisation can be more flexible by allowing individuals to have more authority to solve problems and cut through bureaucracy.

It’s a fascinating approach to creating more autonomy, increase flow and a higher performing organisation. If Windows and MacOs are to an agile organisation then it’s more like mobile O/S for the organisation. I’m starting to ask what if we tried this, how could we, where will the benefits be. A great video to learn more about Holocracy is by Brian Robertson: https://www.youtube.com/watch?v=tJxfJGo-vkI.

15880-DevOps-World-LogoWhat are you hoping to achieve by attending the DevOps World?

As with all conferences there is a bit of promoting our brand through the promotion of the exciting and great work we’re doing at Ticketmaster but also to use it as a learning opportunity to hear more about Devops, maybe we can use the information to extend our own DevOps strategy, or learn what not to try potential risks to watch out for, from other people and to meet new people to make relationships.

developers, Enterprise IT, Infectious Media, Interviews

Infectious Media CTO on how DevOps is affecting ICT teams

people_daniel_de_sybelThe fourth employee of Infectious Media, Dan de Sybel started his career as an Operations Analyst for Advertising.com, where during a six year tenure, he launched the European Technology division, producing bespoke international reporting and workflow platforms, as well as numerous time saving systems and board level business intelligence.

Dan grew the EU Tech team to 12 people before moving agency side, to Media Contacts UK, part of the Havas Media Group. At Havas, Dan was responsible for key technology partnerships and spearheading the agency’s use of the Right Media exchange under its Adnetik trading division.

At Infectious Media, Dan’s Technology division yielded one of the first Big Data analysis systems to reveal and visualise the wealth of information that RTB provides to its clients. From there, the natural next step was to produce the Impression Desk Bidder to be able to action the insights gained from the data in real time and thus close the loop on the programmatic life cycle. Dan’s team continues to enhance its own systems, whilst integrating the technology of other best-in-class suppliers to provide a platform that caters to each and every one of our clients’ needs.

Ahead of his presentation at DevOps World on November 4th in London, Dan shares his insights on how he feels DevOps is affecting ICT teams, the DevOps challenges he is facing as well as what he is doing to overcome it.

What does your role involve and how are you involved with DevOps?

​Infectious Media runs its own real-time bidding software that takes part in hundreds of thousands of online auctions for online advertising space every second. As CTO, it’s my job to ensure we have the right team, processes and practices in place to ensure this high frequency, low latency system remains functional 24×7 and adapts to the ever changing marketplace and standards of the online advertising industry.

DevOps practices naturally evolved at Infectious Media due to our small teams, 1 week sprint cycles and growing complexity of systems. Our heavy use of the cloud meant that we could experiment frequently with different infrastructure setups and adapt code to deliver the best possible value for the investment we were prepared to make. These conditions resulted in far closer working of the developers and the operational engineers and we have not looked back since.

How have you seen DevOps affecting IT teams’ work?

Before adopting the DevOps philosophy, we struggled to bring the real-time bidding​ system to fruition, never sure if problems originated in the code, in the operational configurations of infrastructure, or in the infrastructure itself. Whilst the cloud brought many benefits, never having complete control of the infrastructure stack led to ​many latency and performance issues that could not be easily explained. Furthermore, being unable to accurately simulate a real-world environment for testing without spending hundreds of thousands of pounds meant that we had to work out solutions for de-risking testing new code in live environments. All of these problems became much easier to deal with once we started following DevOps practices and as a result, we have a far happier and more productive technology team.

What is the biggest challenge you are facing with DevOps and how did/are you trying to overcome it?

​The biggest challenge was overcoming initial inertia to switch to a model that was so far unproven and regarded as a bit of a fad. Explaining agile methodologies and the compromises it involves to senior company execs is hard enough, but as soon as you mention multiple daily release cycles necessitating fewer governance processes and testing on live, you are bound to raise more than a few eyebrows.​

​Thankfully, we are a progressive company and the results proved the methodology. Since we adopted DevOps, we’ve had fewer outages, safer, more streamlined deployments and, crucially, more features released in less time

Can you share a book, article, movie that you recently read/watched and inspired you – in regards to technology?

​The Phoenix Project. ​Perhaps a bit obvious, but it’s enjoyable reading a novel that covers some of the very real problems IT professionals experience in their day-to-day roles with the very solutions that we were experimenting with at the time.

15880-DevOps-World-LogoWhat are you hoping to achieve by attending the DevOps World?

​Really my goal is to understand and help with some of the problems rolling DevOps practices out across larger companies can yield. In many respects, rolling out DevOps in small startups is somewhat easier as you have far less inertia from tried and trusted practices, comparatively less risk and far fewer people to convince that it’s a good idea. I’ll be interested to hear about other people’s experiences and hopefully be able to share some advice based on our own.

Ansible, M&A, News & Analysis, Open Source, RedHat

RedHat to buy DevOps specialist Ansible

Cloud in my handOpen source vendor RedHat has announcement an agreement to buy DevOps specialist Ansible, which creates agentless automation systems designed to simplify the automation of pure and across hybrid cloud environments.

The upstream Ansible open source automation projects on GitHub have an active community of 1,200 contributors and Ansible automation is used by Fortune 100 companies to power large and complex private cloud environments. In 2015 it was granted the InfoWorld Bossie Award in recognition of being the best open source datacentre and cloud software on the market.

Ansible removes some of the most significant barriers to automation across IT, according to Joe Fitzgerald vice president of management at Red Hat. Adding Ansible to Red Hat’s hybrid management portfolio means customers can install and manage cloud applications more easily, use DevOps to improve service delivery, streamline OpenStack projects and make container adoption much easer to orchestrate and configure.

Acquiring the top IT automation and DevOps company will take Red Hat significantly closer to frictionless IT, according to Fitzgerald, but innovation has to be 100 per cent open source and built on open management. “Ansible can help us relentlessly focus on reducing cost and complexity through ease of use and automation,” said Fitzgerald.

The addition of Ansible to Red Hat’s portfolio puts it at the forefront of cloud and DevOps, according to venture capitalist Doug Carlisle, MD of Menlo Ventures.

The acquisition, which will close in October if all conditions are met, won’t affect Red Hat’s revenue for the third and fourth quarters of its fiscal year ending on February 29, 2016. The terms of the deal were not disclosed, but VentureBeat reckons the price was over $100 million.

Management expects that non-GAAP operating expenses for fiscal 2016 will increase by approximately $2.0 million, or ($0.01) per share, in the third quarter and approximately $4.0 million, or ($0.02) per share, in the fourth quarter as a result of the transaction.

According to researcher IDC’s analysis in July 2015, the global cloud systems management software market achieved total revenue of $2.3 billion in 2014. The market is currently forecast to grow to $8.3 billion in 2019.

Cloud computing, Featured, IaaS, ITBM, PaaS

5 Cloud Predictions for 2014

By John Dixon, LogicsOne

 

Here are my 5 Cloud Predictions for 2014. As always, leave a comment below and let me know what you think!

1. IaaS prices will drop by at least 20%

Amazon has continued to reduce its pricing since it first launched its cloud services back in 2006. In February of last year, Amazon dropped its price for the 25th time. By April prices dropped for the 30th time and by the summer it was up to 37 times. Furthermore, there was a 37% drop in hourly costs for dedicated on-demand instances. Microsoft announced that they will follow AWS’s lead with regard to price cuts. I expect this trend to continue in 2014 and likely 2015. I highlight some of these price changes and the impact it will have on the market as more organizations embrace the public cloud in more detail in my eBook.

2. We’ll see signs of the shift to PaaS

Amazon is already starting to look more like a PaaS provider than an IaaS provider. Just consider pre-packaged, pre-engineered features like Auto Scaling, CloudWatch, SQS, RDS among other services. An application hosted with AWS that uses all of these features looks more like an AWS application and less like a cloud application. Using proprietary features is very convenient, but don’t forget how application portability is impacted. I expect continued innovation in the PaaS market with new providers and technology, while downward price pressures in the IaaS market remain high. Could AWS (focusing on PaaS innovation) one day source its underlying infrastructure to a pure IaaS provider? This is my prediction for the long term — large telecoms like AT&T, Verizon, BT, et al. will eventually own the IaaS market, Amazon, Google, Microsoft will focus on PaaS innovation, and use infrastructure provided by those telecoms. This of course leaves room for startup, niche PaaS providers to build something innovative and leverage quality infrastructure delivered from the telecoms. This is already happening with smaller PaaS providers. Look for signs of this continuing in 2014.

3. “The cloud” will not be regulated

Recently, there have been rumblings of regulating “the cloud” especially in Europe, and that European clouds are safer than American clouds. If we stick with the concept that cloud computing is just another way of running IT (I call it the supply chain for IT service delivery), then the same old data classification and security rules apply. Only now, if you use cloud computing concepts, the need to classify and secure your data appropriately becomes more important. An attempt to regulate cloud computing would certainly have far reaching economic impacts. This is one to watch, but I don’t expect any legislative action to happen here in 2014.

4. More organizations will look to cloud as enabling DevOps

It’s relatively easy for developers to head out to the cloud, procure needed infrastructure, and get to work quickly. When developers behave like this, they not only write code and test new products, but they become the administrators of the platforms they own (all the way from underlying code to patching the OS) — development and operations come together. This becomes a bit stickier as things move to production, but the same concept can work (see prediction #5).

5. More organizations will be increasingly interested in governance as they build a DevOps culture

As developers can quickly bypass traditional procurement processes and controls, new governance concepts will be needed. Notice how I wrote “concepts” and not “controls.” Part of the new role of the IT department is to stay a step ahead of these movements, and offer developers new ways to govern their own platforms. For example, a real time chart showing used vs. budgeted resources will influence a department’s behavior much more effectively than a cold process that ends with “You’re over budget, you need to get approval from an SVP (expected wait time: 2-8 weeks).”

DevOps CIO Dashboard

 Service Owner Dashboard

The numbers pictured are fictitious. With the concept of Service Owners, the owner of collaboration services can get a view of the applications and systems that provide the service. The owner can then see how VoIP spending is a little above the others, and drill down to see where resources are being spent (on people, processes, or technology). Different ITBM applications display these charts differently, but the premise is the same – real time visibility into spend. With cloud usage in general gaining steam, it is now possible to adjust the resources allocated to these services. With this type of information available to developers, it is possible to take proactive steps to avoid compromising the budget allocated to a particular application or service. On the same token, opportunities to make informed investments in certain areas will become exposed with this information.

So there you have it, my 2014 cloud predictions. What other predictions do you have?

To hear more from John, download his eBook “The Evolution of Your Corporate IT Department” or his Whitepaper “Cloud Management, Now“

 

 

Amazon AWS, Chef, Configuration management, Free, Nginx, Tools

AWS Unveils OpsWorks Cloud DevOps Solution

Amazon AWS just announced DevOps (beta) a no-charge solution for managing applications in the AWS cloud using Chef recipes, built on technology developed by Peritor, the creators of Scalarium, which was acquired by AWS in 2012:

AWS OpsWorks is a DevOps solution for managing applications of any scale or complexity on the AWS cloud. AWS OpsWorks features an integrated experience for managing the complete application lifecycle, including resource provisioning, configuration management, application deployment, software updates, monitoring, and access control. 

AWS OpsWorks lets you model and visualize your application with layers that define how to configure a set of resources that are managed together. You can also define the software configuration for each layer, including installation scripts and initialization tasks. When an instance is added to a layer, all the configuration steps are applied for you. AWS OpsWorks promotes conventions but is flexible enough to let you customize any aspect of your environment. Since AWS OpsWorks uses Chef recipes, you can leverage hundreds of community-built configurations such as PostgreSQL, Nginx, and Solr.

Read details.

 

Cloudify, GigaSpaces Technologies, GitHub, Open Source, OpenStack, OpsCode, Partnerships, Rackspace

Gigaspaces Cloudify Partners with OpSpaces for Chef Onboarding

GigaSpaces Technologies, with its new release of the open source Cloudify product, has partnered with OpsCode for a dedicated Chef integration that caters to diverse application stacks and systems.

“The concept of DevOps and recipes can go well beyond setup, to actually manage the entire lifecycle of your applications—from setup, to monitoring, through maintaining high availability, and auto-scaling when required.  This is where Cloudify and Chef come together,” says Bryan Hale, Director of Business Development for OpsCode. “By enabling users to leverage the power and variety of Chef recipes and cookbooks to deploy services, Cloudify supports comprehensive application level orchestration on any cloud.”

In addition to the integration with Chef, this new release also includes the following features:

  • Complete application-level orchestration, allowing automated provisioning, deployment, management and scaling of complex multi-tier apps to any cloud environment
  • Built-in, ready to use recipes for common big data components, such as Hadoop, Cassandra and MongoDB.
  • Support for non-virtualized environments (AKA Bring Your Own Node), allowing you to treat an arbitrary set of server as your “Cloud” and have Cloudify deploy and manage applications on these servers.
  • Comprehensive REST API for easy integration with third-party tooling and programmatic access.
  • Support for all the common cloud infrastructures, including OpenStack, HPCloud, RackSpace, Windows Azure, Apache CloudStack, Amazon AWS and vCloud.

In addition, Cloudify now also simplifies the complexities involved with deploying big data applications to the cloud.  It is well-known that the massive computing and storage resources that are needed to support big data deployments make cloud environments, public and private, an ideal fit.  But managing big data application on the cloud is no easy feat – as these systems and applications often include other services such as relational and non-relational databases, stream processing tools, web front ends and more, where each framework comes with its own management, installation, configuration, and scaling mechanisms.  With its new built-in recipes, Cloudify provides consistent management and cloud portability for popular big data tools, exponentially reducing the operational and infrastructure costs involved with running these systems.

“We’re seeing a growing market trend for the need to migrate applications – not just in one-off processes anymore – but on a much larger scale, by enterprises, managed service providers, and ISVs alike, who are looking to take advantage of the cloud promise—while until now, only about 5% have actually been able to do so,” says Uri Cohen, Vice President of Product Management at GigaSpaces. “The beauty of Cloudify and its recipe-based model is that it enables you to simply and smoothly take both new and existing applications to the cloud by the tens and hundreds through Cloudify’s built-in recipes and the new integration with OpsCode’s Chef, in very short time frames.”

You can fork the Cloudify code from GitHub, or download the Cloudify GA release.

AppFirst, Business transaction management, Partnerships

AppFirst Launches New Partner Program

AppFirst, the SaaS application management system, today unveiled a comprehensive new Partner Program designed for both Cloud and Solution Providers. The program offers a new, expanded free subscription available only via AppFirst partners and provides ongoing training and product support, enabling partners to deliver innovative solutions to their own customers. The rollout of this Partner Program follows the company’s launch earlier this month of its new DevOps Dashboard, an application performance monitoring solution that delivers a clear, unified status view of infrastructure, applications and business metrics to all stakeholders in an organization.

“Our focus today is on growing our global ecosystem to increase the number of AppFirst experts as well as the overall availability of our product,” said David Roth, AppFirst CEO. “By offering access to our solutions through the primary source customers use to deploy their applications in the cloud, our Partner Program complements our partners’ solutions with AppFirst technology, delivering added value to our respective customers. This expanded universe is designed to provide our partners with the solutions and support they need to succeed and grow within their own markets.”

Under the Cloud Provider Partner Program, qualified cloud service providers such as Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) can offer the enhanced free version of AppFirst to its customers via their own marketplace or dashboards, as an extension or add-on to their own service. AppFirst partners deliver value to their end customers by offering a solution that provides the visibility needed across the infrastructure, application and business as an application is running in production, with the added benefit of AppFirst’s extended free program.

“In today’s online world, keeping applications and websites up and running is business critical,” said Mal Knox, Director of Business Development at Engine Yard. “With Engine Yard Cloud, we provide the tools and resources to ensure the optimum performance of our customers’ applications. Partnering with companies like AppFirst enables us to deliver enhanced performance monitoring services, giving customers the visibility they need.”

Solution Provider Partners, which include systems integrators, application development shops and cloud consultancies, will have access to AppFirst products and training, while also receiving implementation tools and assistance, technical resources and implementation support from the company. As these partners become competent with AppFirst’s solutions, they can integrate them in their customer deliverables and even customize and optimize the solution. Solution Providers are also able to offer the free version to their clients, allowing direct visibility into the applications their customers want to actively monitor themselves. Building a global ecosystem of trained Solution Provider Partners allows AppFirst to scale to deliver implementation and industry-specific configuration services at the local level through their partners.

Because AppFirst’s DevOps Dashboard is also easily customizable, any partner company can offer broad custom solutions for internal use, and for their own customers, whether executives, IT ops or DevOps.

“Our customers, with our assistance, are making strategic decisions about if, when and how they migrate to cloud,” said Eileen Boerger, president of CorSource Technology Group. “Partnering with AppFirst provides us another tool in our quiver to assist with those decisions. With the DevOps Dashboard being so customizable, that allows us to provide individualized solutions for our customers, something they demand.”

AppFirst collects millions of infrastructure, application and business metrics that are aggregated and correlated in a single big data repository that eliminates the need for users to look for data in multiple places. Data is collected continuously to provide customers with unprecedented visibility into their entire infrastructure and every application running in production, bringing overall system management to a whole new level.

The DevOps Dashboard’s ability to auto-detect application stacks and configure data collection from the relevant sources delivers a customized dashboard specific to the user’s environment — all automatically, with no extra effort required. With the smart threshold feature, AppFirst time learns over time what is “normal” for a user’s business metrics and delivers alerts when metrics shift one standard deviation from normal levels, saving time and money.

For more information on AppFirst’s Partner Programs, please visit the AppFirst partner section or call 1.800.782.2181.


Uncategorized

The Operational Consistency Proxy

#devops #management #webperf Cloud makes more urgent the need to consistently manage infrastructure and its policies regardless of where that infrastructure might reside

f5friday

While the potential for operational policy (performance, security, reliability, access, etc..) diaspora is often mentioned in conjunction with cloud, it remains a very real issue within the traditional data center as well. Introducing cloud-deployed resources and applications only serves to exacerbate the problem.

F5 has long offered a single-pane of glass management solution for F5 systems with Enterprise Manager (EM) and recently introduced significant updates that increase its scope into the cloud and broaden its capabilities to simplify the increasingly complex operational tasks associated with managing security, performance, and reliability in a virtual world.

f5em2.0AUTOMATE COMMON TASKS

The latest release of F5 EM includes enhancements to its ability to automate common tasks such as configuring and managing SSL certificates, managing policies, and enabling/disabling resources which assists in automating provisioning and de-provisioning processes as well as automating what many might consider mundane – and yet critical – maintenance window operations.

Updating policies, too, assists in maintaining operational consistency across all F5 solutions – whether in the data center or in the cloud. This is particularly important in the realm of security, where control over access to applications is often far less under the control of IT than even the business would like. Combining F5’s cloud-enabled solutions such as F5 Application Security Manager (ASM) and Access Policy Manager (APM) with the ability for F5 EM to manage such distributed instances in conjunction with data center deployed instances provides for consistent enforcement of security and access policies for applications regardless of their deployment location. For F5 ASM specifically, this extends to Live Signature updates, which can be downloaded by F5 EM and distributed to managed instances of F5 ASM to ensure the most up-to-date security across enterprise concerns.

The combination of centralized management with automation also ensures rapid response to activities such as the publication of CERT advisories. Operators can quickly determine from the centralized inventory the impact of such a vulnerability and take action to redress the situation.

INTEGRATED PERFORMANCE METRICS real-time-app-perf-monitoring-cloud-dc

F5 EM also includes an option to provision a Centralized Analytics Module. This module builds on F5’s visibility into application performance based on its strategic location in the architecture – residing in front of the applications for which performance is a concern. Individual instances of F5 solutions can be directed to gather a plethora of application performance related statistics, which is then aggregated and reported on by application in EM’s Centralized Analytics Module.

These metrics enable capacity planning, troubleshooting and can be used in conjunction with broader business intelligence efforts to understand the performance of applications and its related impact whether those applications are in the cloud or in the data center. This global monitoring extends to F5 device health and performance, to ensure infrastructure services scale along with demand. 

Monitoring includes:

  • Device Level Visibility & Monitoring
  • Capacity Planning
  • Virtual Level & Pool Member Statistics
  • Object Level Visibility
  • Near Real-Time Graphics
  • Reporting

In addition to monitoring, F5 EM can collect actionable data upon which thresholds can be determined and alerts can be configured.

Alerts include:

  • Device status change
  • SSL certificate expiration
  • Software install complete
  • Software copy failure
  • Statistics data threshold
  • Configuration synchronization
  • Attack signature update
  • Clock skew

When thresholds are reached, triggers send an alert via email, SNMP trap or syslog event. More sophisticated alerting and inclusion in broader automated, operational systems can be achieved by taking advantage of F5’s control-plane API, iControl. F5 EM is further able to proxy iControl-based applications, eliminating the need to communicate directly with each BIG-IP deployed.

OPERATIONAL CONSISTENCY PROXY

By acting as a centralized management and operational console for BIG-IP devices, F5 EM effectively proxies operational consistency across the data center and into the cloud. Its ability to collect and aggregate metrics provides a comprehensive view of application and infrastructure performance across the breadth and depth of the application delivery chain, enabling more rapid response to incidents whether performance or security related.

F5 EM ensures consistency in both infrastructure configuration and operational policies, and actively participates in automation and orchestration efforts that can significantly decrease the pressure on operations when managing the critical application delivery network component of a highly distributed, cross-environment architecture.

Additional Resources:

Happy Managing!

Connect with Lori: Connect with F5:
o_linkedin[1] google  o_rss[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1] google

Related blogs & articles:

read more

Apache Tomcat, Cloudify, Guest Post, MySQL, Rackspace

Bursting into the Clouds – Experimenting with Cloud Bursting

Guest Post by Dotan Horovits, Senior Solutions Architect at GigaSpaces

Dotan Horovits is one of the primary architects at GigaSpaces

Dotan Horovits is one of the primary architects at GigaSpaces

Who needs Cloud Bursting?

We see many organizations examining Cloud as replacement for their existing in-house IT. But we see interest in cloud even among organizations that have no plan of replacing their traditional data center.

One prominent use case is Cloud Bursting:

Cloud bursting is an application deployment model in which an application runs in a private cloud or data center and bursts into a public cloud when the demand for computing capacity spikes. The advantage of such a hybrid cloud deployment is that an organization only pays for extra compute resources when they are needed.
[Definition from SearchCloudComputing]

Cloud Bursting appears to be a prominent use case in cloud on-boarding projects. In a recent post, Nati Shalom summarizes nicely the economical rationale for cloud bursting and discusses theoretical approaches for architecture. In this post I’d like to examine the architectural challenges more closely and explore possible designs for Cloud Bursting.

Examining Cloud Bursting Architecture

Overflowing compute to the cloud is addressed by workload migration: when we need more compute power we just spin up more VMs in the cloud (the secondary site) and install instances of the application. The challenge in workload migration is around how to build a consistent environment in the secondary site as in the primary site, so the system can overflow transparently. This is usually addressed by DevOps tools such as Chef, Puppet, CFEngine and Cloudify, which capture the setup and are able to bootstrap the application stack on different environments. In my example I used Cloudify to provide consistent installation between EC2 and RackSpace clouds.

The Cloud Bursting problem becomes more interesting when data is concerned. In his post Nati mentions two approaches for handling data during cloud bursting:

1. The primary site approach – Use the private cloud as the primary data site, and then point all the burst activity to that site.
2. Federated site approach – This approach is similar to the way Content Distribution Networks (CDN) work today. With this approach we maintain a replica of the data available at each site and keep their replicas in sync.

The primary site approach incurs heavy penalty in latency, as each computation needs to make the round trip to the primary site to get the data for the computation. Such architecture is not applicable to online flows.

The federated site approach uses data synchronization to bring the data to the compute, which saves the above latency and enables online flows. But if we want to support “hot” bursting to the cloud, we have to replicate the data between the sites in an ongoing streaming fashion, so that the data is available on the cloud as soon as the peak occurs and we can spin up compute instances and immediately start to redirect load. Let’s see how it’s done.

Cloud Bursting – Examining the Federated Site Approach

Let’s put up our sleeves and start experimenting hands-on with the federated site approach for Cloud Bursting architecture. As reference application let’s take Spring’s PetClinic Sample Application and run it on an Apache Tomcat web container. The application will persist its data locally to a MySQL relational database.

The primary site, representing our private data center, will run the above stack and serve the PetClinic online service. The secondary site, representing the public cloud, will only have a MySQL database, and we will replicate data between the primary and secondary sites to keep data synchronized. As soon as the load on the primary site increases beyond a certain threshold, we will spin up a machine with an instance of Tomcat and the PetClinic application, and update the load balancer to offload some of the traffic to the secondary site.

On my experiment I used Amazon EC2 and RackSpace IaaS providers to simulate the two distinct environments of the primary and secondary sites, but any on-demand environments will do.

REPLICATING RDBMS DATA OVER WAN

How do we replicate data between the MySQL database instances over WAN? On this experiment we’ll use the following pattern:

1.     Monitor data mutating SQL statements on source site. Turn on the MySQL query log, and write a listener (“Feeder”) to intercept data mutating SQL statements, then write them to GigaSpaces In-Memory Data Grid.

2.     Replicate data mutating SQL statements over WAN. I used GigaSpaces WAN Replication to replicate the SQL statements  between the data grids of the primary and secondary sites in a real-time and transactional manner.

3.     Execute data mutating SQL statements on target site. Write a listener (“Processor”) to intercept incoming SQL statements on the data grid and execute them on the local MySQL DB.

 

 

 

 

 

 

 

 

 

 

 

 

To support bi-directional data replication we simply deploy both the Feeder and the Processor on each site.

AUTO-BOOTSTRAP SECONDARY SITE

When peak load occurs, we need to react immediately, and perform a series of operations to activate the secondary site:

1.     spin up compute nodes (VMs)

2.     download and install Tomcat web server

3.     download and install the PetClinic application

4.     configure the load balancer with the new node

5.     when peak load is over – perform the reverse flow to tear down the secondary site

We need to automate this bootstrap process to support real-time response to peak-load events. How do we do this automation? I used GigaSpacesCloudify open-source product as the automation tool for setting up and for taking down the secondary site, utilizing the out-of-the-box connectors for EC2 and RackSpace. Cloudify also provides self-healing  in case of VM or process failure, and can later help in scaling the application (in case of clustered applications).

Implementation Details

The result of the above experimentation is available on GitHub. It contains:

§  DB scripts for setting up the logging, schema and demo data for the PetClinic application

§  PetClinic application (.war) file

§  WAN replication gateway module

§  Cloudify recipe for automating the PetClinic deployment

See the documentation on GitHub for detailed instructions on how to configure the above with your specific deployment details.

Conclusion

Cloud Bursting is a common use case for cloud on-boarding, which requires good architecture patterns. In this post I tried to suggest some patterns and experiment with a simple demo, sharing it with the community to get feedback and raise discussion on these cloud architectures.

More information can be seen at an upcoming GigaSpaces webinar on Transactional Cross-Site Data Replication on June 20th (register at: http://bit.ly/IM0w9F)


GigaSpaces, Guest Post, No-Ops, PaaS, Platform as a service

Does PaaS Really Mean No-Ops?

Guest post by Yaron Parasol, Director of Product Management, GigaSpaces

Yaron Parasol is GigaSpaces Director of Product Management

I’d like to start with a brief overview of the evolution of the cloud – and why I think a new approach to PaaS solutions is needed – and the best scenarios for this to come into play.

First there was IaaS. Cloud was created with the notion of IT agility and cost-reduction. You need servers? No problem! Forget about red tape, forget about sys admins. You create an account and in few clicks you select the hardware profile and OS image you need, and voila, your server is out there, ready for you to use. No hassles, immediate gratitude.

Well, this is true as long as the images you get form your cloud provider match your needs. If you have custom needs, you will have to create and maintain your own image. So, you need the sys admin’s knowledge. However, we’re also seeing a change in methodology here – sys admins no longer need to install the servers once they’re up. Instead, they provide their expertise using approved and maintained images on the cloud. Application developers can choose the right image for them and from that point on, create virtual machines in the amount and hardware size they need for their applications.

Now let’s switch to PaaS. The idea of no-ops is the guideline for many of the existing PaaS offerings. Their use cases and features are all about developers. As Michael Cote put it:

“The point of PaaS is to make a developer’s life even easier: you don’t need to manage your cloud deployments at the the lower level of IaaS, or even wire together your Puppet/Chef scripts. The promise of PaaS is similar to that of Java application servers: just write your applications (your business logic) and do magic deployment into the platform, where everything else is taken care of.”

Developers need to deploy applications to the Cloud. They don’t want to care about the OS but they also don’t want to care about platforms, load balancers etc. They want to focus on what they know – writing code.

This is definitely a very productive approach for some developers and some applications. Reality shows that a big portion of Cloud users don’t find these solutions a good fit for their purposes. These users continue to deploy and manage their applications on infrastructure clouds, as if they were running on premise leveraging the good old Ops folks. Others have taken a more agile approach, using configuration management and automation tools such as Chef.

These users chose not to use PaaS because they need flexibility and control. PaaS doesn’t seem to answer a lot of the current IT challenges – see for example here and here.

Existing applications with a variety of platforms, some using extremely complex topologies (like Hadoop, or a sharded MongoDB setup) are some of the reasons why PaaS won’t cut it for many users.

They would like to install their chosen versions of their preferred platforms, use their OS image, with their configured security groups, tune them in a manner that fits their applications and deploy their applications with the topology they choose.

Chef, like other DevOps tools, go a long way here and helps to achieve the flexibility while re-establishing a new agile relationship between Dev and Ops. Ops bring in their knowledge and skillset, but they document it and maintain it as code in a more structured and configurable way. This in turn gives the application guys the agility they need, putting a complex application to work in a single click and eliminating the platform black box experience which they dislike so much.

Application vs. Separate Platforms

However, DevOps tools still fall short when it comes to managing applications. They are not aware of the application’s inner dependencies. They don’t know how to monitor the application, scale it or even run a complex multi-tier recovery process. Most of these tools can’t even provision an entire application on the cloud.

So what if you could extend the DevOps experience to apply to the entire application lifecycle?

What if you could use Chef and the likes for installation but not stop there – automate things like failover and recovery, and even monitoring and scaling? You will still have all the Ops wisdom tailored to each of your applications and be able to automate any of your existing applications without re-architecting them.

This is exactly our take on PaaS, a DevOps style process that can describe any application’s lifecycle on any runtime environment, providing full automation without taking away the control.  And this is exactly what we set out to do with our Open Source PaaS platform – Cloudify, borrowing the idea of recipes but extending it to be application-centric and not infrastructure-centric.

The recipe describes the application dependencies and lifecycle events externally without any code or architecture change.

lifecycle{
init "mongod_install.groovy"
start "mongod_start.groovy"
postStart "mongod_poststart.groovy"
}

view rawmongod.groovyThis Gist brought to you by GitHub.

See how to create your own recipes here.

Mapping events like installation, start, post-start and stop to scripts or Chef cookbooks, exposing groovy andREST interfaces for context sharing and dynamic configuration and even provide a way to describe monitoring techniques, scaling rules and process “liveness” detection.

So think about it this way: while most PaaS services come with a catalog of predefined application blueprints, allowing the user to control only the application code, this new kind of PaaS stack, allows the user to define the blueprint, that is – any blueprint!

So, the recipes combine the Ops expertise with the power of automation for the developers. They completely remove the lock-in risk from the application-stack perspective.

You can read more the recipes, download Cloudify and experience it yourself or even join the community and influence the roadmap at cloudifysource.org. Or you can come see more when we present at HP Discover next week in Las Vegas.