Interested in how DevOps, IT Modernization and Agile practices can positively impact customer experience?
Having a DevOps approach for application or product development is like H2O to your organization. It’s a basic need to live long and prosper. Yes, DevOps is like H2O: High-quality bug-free apps and products Heights of innovation One-click deployments And a lot more to be honest! Whether you’re a dev or ops guy, chances are you are constantly being educated about a DevOps approach or methodology. You might even be aware of the myths and facts of DevOps and how a DevOps infrastructure affects your customers. The questions to ask are these: How do you know you aren’t using DevOps? And, isn’t it time you think of an investment in DevOps? Because DevOps is a culture –a process, there’s no definite checklist that you can use to understand your DevOps stand. The current state-of-the-art DevOps approach does not provide a ready-to-use framework or manifesto. However, there are a lot of best practices and indicators that can help you understand where you stand when it comes to DevOps. We’ve put together a list of five signs, or indicators, (it’s not THE list, as there’s no specific checklist) that, when relatable, implies you’re missing out from DevOps at the very core. In that case, you need to call for a team meeting to start thinking DevOps. Sign #1: Your team has the best developers, but an application deployment takes three times longer than it’s supposed to take. This clearly indicates that your feedback loop is at stake. Whether it’s a local feedback loop, wherein the developer does local testing before the code is sent to QA, or a feedback that a developer receives from QA, it’s significant to send feedback to the developer as quickly as possible. Why? Context switching.
Recently, Foote Partners, an IT benchmark research and advisory firm, released data on the most in-demand skills and certifications in the IT market. We weren’t surprised to see cloud architecture experts topping the list, or to be specific, architecture and cloud skills. An article about the survey is here, from FierceCIO: “Architecture and cloud skills top IT employer ‘most wanted’ lists.” In our cloud consulting work at Flux7, we see this to be a real need in enterprises, mid-sized organizations, and particularly in startups. Naturally, as the cost of skilled labor in an area such as cloud architecture increases, cash-strapped startups start to feel the pinch. But, these startups feel the effect of poor choices from the lack of cloud architecture expertise just as much, if not more, than enterprises. We’ve recently seen several cases where startups have launched environments in Heroku because of it’s ease of use, but then found the need to migrate from Heroku to AWS in order to meet compliance or scalability requirements. We’ve also seen a number of situations where a startup or mid-sized organization was set up in AWS, but needed to get this environment production-ready. Often, a bit of planning and work upfront could have saved these startups time and resources to execute a cloud migration. And, it’s rare to start a cloud migration until the pressing need is there: such as that critical demo for an investor or customer; or even an anticipated sudden increase in demand from a marketing campaign. Because startups need access to cloud architecture experts, too, we’ve created a new service: Cloud Attune. Cloud Attune helps incubators, VC firms and bootstrapped startups.
In previous posts, Understanding Chef Basics with 3Q’s and Delving into More Chef Basics, we started you on a journey to become better acquainted with Chef elements, their functions, node objects, policies and cookbooks. Now that you likely have the fundamentals of Chef in your pantry, today, let’s start cooking with Chef. In this post, you will learn how to install a hosted Chef server and Chef client. As we noted before, Chef servers come in two flavors: 1. Hosted Chef Server 2. On-Premise Chef Server To start, let’s set up hosted Chef Server. Step1: Signup for Free Hosted Chef Server (get up to 5 nodes free) After you sign up, Chef requires that you are already part of an organization or that you create a new one. I’ve created a new sample organization for the purpose of this article: When you provide an organization name and a short name, the following dashboard is displayed: Step 2: Install Chef-Repo Next, click on the “Download Starter Kit” button and download the Chef-starter zip folder to a root directory. After extracting it, the Chef-repo folder is available.
Last week, RackSpace announced its intention to remove unmanaged cloud service offerings. You can read about it here: Where does IaaS fit into the managed Cloud. In some aspects, this decision is a surprise. But, if you were paying attention, you’d agree it was bound to happen. So why should we have known this was going to happen? Change Is in the Air During the past few years, the cloud has proven itself to be the future. And RackSpace has been in the cloud business since the beginning. But the truth of the matter is well laid out here: http://bit.ly/1svqeKN. At the same time, when the cloud has proven itself to be the future, RackSpace’s stock price has steadily fallen. It’s obvious that RackSpace’s strategy of competing head on with Amazon wasn’t working and they needed a new strategy. Which brings us to why they were losing in this space. Band of Gorillas RackSpace is a relatively small company. It was fighting the industry’s 800-pound gorilla called AWS. For a company with a market cap of $4-billion to compete head on with a company that has a market cap nearly 30 times more is difficult. But, it makes it a competitor notorious for living under low profit margins, and the battle RackSpace faced during the past few years becomes more apparent. What’s more, there hasn’t been any good news for RackSpace. Before RackSpace was competing against the 800-pound gorilla. Now, there’s a band of silverbacks baring their teeth, vying for dominance. Google, Microsoft, IBM. All of them are determined to get a slice of the cloud. To stay in the market, RackSpace has had to sidestep them. This is especially due to the value added from the cloud being able to scale your infrastructure.
It’s a well-known fact that we, as humans, tend to have this secret crush on stats. We are taken in awe when we see numbers. You know what I’m talking about … right? For example, I believe that 75% of you reading this post will feel mind-blown when you read this: “The human eye blinks an average of 4,200,000 times a year.” (Please don’t hold me responsible if this is a false statement. Like you, I just believe the stats!) The truth is … what caught your eye was the number that made itself standout in the sentence. Today, I am going to walk you through some interesting cloud statistics, and even trends, that you should know. By knowing these, you will strengthen your bond with the emerging cloud. There’s been a lot of buzz circling around the cloud. It’s been growing, and growing pretty quickly during the past few years. The reasons for this growth has been well acknowledged by the huge number of cloud adopters. So, we have some pretty good evidences and reasons, too. Read some of our previous posts about the cloud and its benefits in the business world: The Power of Cloud Computing 5 Cloud Advantages You Didn’t Think About Quiz: Is the Cloud Right for Your Business? Successful AWS projects we’ve done at Flux7 Soon, gone will be the days when the cloud is no longer an option, but the only choice to make … whether you like it or not. (That’s rude, isn’t it? Hmm … NO! You’ll find out why. Keep reading!) Following is an infographic which lists some interesting stats in regard to the cloud.
Recently, Amazon Web Services [AWS] began offering different types of EBS drives. Apart from the magnetic EBS drive, there are now two types of Amazon AWS SSD drives: an EBS General Purpose SSD drive and a Provisioned IOPS SSD drive. We thought it would be interesting to perform an ssd drives benchmark for these two drives for MySQL storage. For the MySQL benchmarking, we used Sysbench. The setup instructions and methodology for running the benchmark are explained here in this post titled Using Sysbench to benchmark MySQL. Our setup for these benchmarks is similar to that of our previous post, except that the storage used is EBS instead of instance store. Here are the specifications of the system under test: Machine: AWS m3.large instance (64 Bit, paravirtual, 2 vCPUs, 7.5GB RAM) OS: Ubuntu 14.04 LTS (3.13.0-24-generic) MySQL Version: 5.5.35 Sysbench Version: 0.4.12 EBS Magnetic Drive Using a magnetic drive provides the lowest cost per GB compared to all other types of EBS storage drives. Magnetic volumes are at approximately 100 IOPS on average, with an ability to burst to hundreds of IOPS. We ran both benchmarks with and without the optimizations applied. The optimization applied is explained in detail here. Following are the results of the benchmarks run on the EBS magnetic drive. We see here that TPS deteriorates when the table size is increased. For small-sized tables, we see that TPS is really good and comparable to EBS SSD-backed drives. Provisioned IOPS (SSD) EBS Drives Here, the EBS drive comes with a consistent IOPS. Even though they cost slightly more than a general purpose SSD, they are recommended for I/O intensive workloads, like databases. Provisioned AWS EBS IOPS volumes support up to 30 IOPS per GB.
“DevOps is not a tool. DevOps involves the human element. It’s about efficient collaboration between the ops and dev teams. DevOps is a process. DevOps is a culture.” Haven’t you already heard enough of this? I know … right! However, in this post, let’s view DevOps in a new angle. Let’s explore what’s in it for your customers. What are the challenges you face that hinder an efficient rendering of services? We all know, no matter what the product or service you are delivering, that the customer is king. And, of course, the goal of any business is to target the right group of people with the right services or products. Following is an outline that summarizes the challenges, scenarios and needs that any organization faces in setting up a DevOps infrastructure. Align Your Team’s Needs With Your Customers’ The first and the foremost goal of any organization is to satisfy its customers. This is even more significant an issue for businesses that deal with varying surges in customer demands. The question to ask is: “How well does your system scale?” The challenges in meeting customer needs start with your organization’s internal teams. Yes … you are responsible. Not being convinced of this statement only implies that you haven’t yet started thinking about DevOps. Some of those challenges being dealt with by your internal teams include: Developer Onboarding: Organizations are bound to change due to new technologies and new hires. This is an inevitable change. However, this also affects internal teams in many ways. Ramping up a new hire to the already existing process of the organization is bound to require handling different levels of difficulty. Continuous Integration: A constant and quick feedback framework is a necessity.
It’s kitchen time again. Put that Chef hat on and let’s check out some more cool stuff. In our last post “Part 1: Understanding Chef Basics with 3 ‘Wh’ Q’s,” I bundled a whole lot of Chef ingredients. (That features for you lay Chefs.) To quickly refresh the list, and your memory, we discussed Chef components and elements using three Wh Q’s: What are the elements of Chef and their functionalities? Chef Nodes: Any machine type that is managed by a Chef-client. Chef Servers: The hub of the organization. Workstation: User-run computer for configuration related tasks. What are the types of Chef elements, if any? Chef Nodes: Physical, cloud, network, virtual machine. Chef Servers: Enterprise Chef, Hosted Enterprise Chef, Open Source Chef. What are the components of Chef elements and their functionalities? Chef Nodes: Chef-client, Ohai. Chef Servers: Search, Manage. Workstation: Knife, Chef-repo. Again, you can read about Chef components and elements in more detail here: “Part 1: Understanding Chef Basics with 3 ‘Wh’ Q’s.” In this post, I’ll discuss a few more major concepts and dive right into setting up Chef for your use. Node Objects As mentioned above, Chef-nodes are nothing more than machines that are managed by Chef-client. Each node has node objects that constitute the important aspects of Chef-client. There are two primary node objects: Attributes Run-list Attributes Attributes are just profiles for each node. They hold any and all details about the node. What do they say about a node? Attributes say three things about a node: its current state, its state at the end of a previous Chef-client run, and its expected state at the end of the current Chef-client run. How do they define a node? Using the current state of the node, it defines cookbooks, roles and environments.
We’re getting ready to kick off a series of interactive webinars focused on addressing issues we’ve uncovered during our recent IT assessments in regard to DevOps and the cloud. So, we thought now is a good time to share an article, featuring Flux7 CEO Aater Suleman, that sifts through how to successfully move to a DevOps culture. The article, posted at DevOps.com, is entitled: “Q&A with Aater Suleman: Successfully Moving to DevOps,” and it answers the questions: What do teams need to do in order to move forward with good workflow? What are some of the common lessons learned in moving to DevOps? What are some of the ways enterprises often fail? What are some easy wins enterprises can achieve when it comes to being able to innovate more quickly? Creating an optimized software development workflow is a key area we focus on during our IT assessments. We strongly believe it should be part of any IT infrastructure audit. It’s essential for web-based businesses that use their sites to deliver services and transact business to shift their thinking about developing and delivering apps in the cloud. Web development workflow is a critical business factor. And creating a stable, secure site supported with a local development environment that streamlines developer workflow and requires minimal maintenance time can help get solutions to market faster. As Aater (@futurechips) stated in the DevOps.com article: “A very strong focus on automation and continuous improvement is required. And to succeed there, you need to monitor developer workflows very cautiously.” We all know that measuring is the first step to improvement. But who is really doing this? We’d love to hear your thoughts and comments. Just send them to us at firstname.lastname@example.org.
It’s time for a change. Undoubtedly, for the good. With the help of movers, migration officers, technicians, and a lot more good souls, Flux7’s blog site has now successfully moved to blog.flux7.com. Our previous home was at flux7.com/blogs. Okay, so I know were overstating things a bit. But, it’s official. Now, you need to make a note of the change! You may ask: What’s different? Then let me tell you. At first glance, you will see that the design and layout haven’t changed much. However, here’s what you can look forward to seeing that’s new: Exciting offers! That includes links to free webinars, white papers, and a lot more DevOps and Cloud resources. A complete compilation of industry updates about DevOps and the Cloud — all in one place! The mission of helping you understand the significance of Devops and the Cloud. And, there’s a whole lot more of what we previously offered: Tutorials Best Practices Benchmarking And more stuff! In addition, we know you should be appreciated for your loyalty to our blog.
Throughout the history of our blog, we have shared many posts in regard to benchmarking, such as explaining how to setup and use sysbench for MySQL benchmarking. You can just do a search in the upper right-hand corner for “benchmarking” to find all of these. Today, we are continuing to add to the library! In this post, we are sharing our experiences using sysbench for MySQL benchmarking. To start, let’s explore the setup we used for benchmarking. Setup Here it is: Machine: AWS m3.large instance (64 Bit, paravirtual) Storage: 32 GB SSD instance store OS: Ubuntu 14.04 LTS (3.13.0-24-generic) MySQL Version: 5.5.35 Sysbench Version: 0.4.12 We used four different tables sizes for our benchmarking. They ranged from 50,000 to 50,000,000 whereby each table is 10 times larger than the previous one. Initially, the benchmark was run without applying any optimization and used the default “my.cnf.” We then applied several optimizations for MySQL based on best practices recommended by MySQL documentation. Then we ran the benchmark again. Optimizations We applied the following optimizations to the MySQL configuration file “my.cnf” (/etc/mysql/my.cnf). A short description of the system variables is given below. Caches and Limits max_heap_table_size → The maximum size for in-memory temporary tables is the minimum of the tmp_table_size and max_heap_table_size values. The default value of tmp_table_size. The default value for max_heap_table_size is 16M and is now set to 32MB so that it will be equal to tmp_table_size. query_cache_size → We increased the query_cache_size so that the results are cached to some extent. thread_cache_size → Although for benchmarking purposes, we do not need to use this variable as there will only be one connection. We have included this just to make sure having this variable does not affect the performance. open_files_limit → Increase the open files limit.
Setting up a deployment process on the cloud means a variety of choices. Most likely, you’re prepared to make some tradeoffs. But, getting a view across these potential tradeoffs can be difficult. Here are six popular deployments and advice for making the best choice for your organization’s needs. Let’s assume you want a deployment for a small startup with fewer than 20 developers, each needing to host a webapp that’s gaining traction and for which rapid growth is expected. Its requirements are as follows: Autoscaling support to handle expected surges in demand. Maximizing developer efficiency by automating tedious tasks and improving dev flow. Encouraging mature processes for building a stable foundation as the codebase grows. Maintaining flexibility and agility to handle hotfixes of a relatively immature codebase. Counting on a few sources to fail, because any of them can cause deployment failure—imagine GitHub failing or a required plugin becoming unavailable. Narrowing the focus a bit more, let’s assume the codebase is using Ruby on Rails, as is often the case. Let’s now discuss 6 deployment methods, their pros and cons. Check out the slide deck below: 6 Ruby on Rails Deployment Methods – A Critical Look from Flux7 While there’s many options for deploying Ruby on Rails in AWS environments, there isn’t a single best solution.