devopsy.kinsta.cloud

Category: DevOps Toolbox

SaaS: Building Tools for the DevOps-Minded

DevOps, Continuous Delivery, Continuous Integration and Continuous Testing are no longer just methodologies and development strategies — they’re all a part of a growing economy within the tech industry.

Great Software-as-a-Service (SaaS) companies such as Chef, Docker and New Relic have done an amazing job of spotting the trends early and building their tools and services around a new wave of development processes. Chef and Docker alone have reportedly raised nearly $250 million, and New Relic went public in 2014.

In fact, this very website is another example of how impactful these new development practices are — as several specialized news outlets have been born out of these revolutionary development strategies. So, not only has the DevOps methodology helped developers create better products, faster; but the process has opened opportunities for technical experts to share their experiences on sites like this, e-books, webinars, conferences and any other way people communicate.

On devopsy.kinsta.cloud, you’ll see the best articles on the web discussing how DevOps is defined in different organizations, why Fortune-500 companies are shifting old practices toward CD and the best practices of CI from industry experts.

In the race to be the most DevOps-friendly solution — no matter the niche — hundreds of startups have been founded and funded, which has only enhanced the toolboxes of thousands of developers. You’d be hard-pressed to find a good SaaS company that doesn’t offer integration with Jenkins CI, TeamCity or Chef, and that’s because not only should a SaaS product solve an important problem, but it should have minimum disruption of your current development process.

With all that in mind, Continuous Testing is one of the most exciting spaces in technology today. Continuous Testing is a process that aims to synchronize testing and QA with dev and ops, which ultimately yields better products more quickly.

There are several factors that make Continuous Testing successful in a team’s software development lifecycle — such as open-source collaboration solutions, test automation APIs and tools to track the historic performance of applications .

With the release of Load Impact Version 3.0, the global performance and load testing SaaS company has announced its latest feature that fits right in with the DevOps mindset: Performance trending.

Performance trending allows users to plot runs of the same test over time. That gives companies a clear view into data that locates patterns of performance degradation or improvement in order to easily validate code and infrastructure changes.

In the spirit of Continuous Testing, DevOps, CD and CI — performance trending improves users’ ability to gain both a low-level and high-level view into the performance of their systems. And with the increased number of tests run by DevOps professionals, performance trending yields valuable information for companies concerned with their application performance — which should be everyone.

Between devopsy.kinsta.cloud and plenty of great conferences and meetups around the world, it’s safe to say this economy of DevOps-minded tools will only continue to grow in the coming years.

July 1, 2015
ElasticBox enhances Container support with new release

ElasticBox announced a new version of their product today that enhances Container support. In yet another example of how important Containers are becoming to today’s software development scene, ElasticBox will now allow you to define microservices as Docker files in containers.

Other enhancements include (from the press release) :

UI Enhancement: Tags now make it easier to sort and find items quickly throughout the product. The rich interface enables IT Ops and Development teams to visually assess the latest status of instances, share and manage boxes, and collaborate easily.

Deployment Policies: New functionality allows policies to be boxes, enabling customers to share virtual infrastructure resources from providers like AWS (Amazon Web Services) without having to expose AWS account specifics. Policies have claims that enable IT Ops to tag virtual machine properties, such as platform, instance type, OS family and more. Like all boxes, these deployment policies are reusable and sharable.

Script Boxes: Script boxes are powerful building blocks that can be shared and reused. Variables and script events are stored here. With the addition of requirements, Script boxes have tags to identify the platform, runtime and infrastructure dependencies of the box. At the time of deployment, the requirements and policy claims can be easily married, so developers can self-service the appropriate infrastructure, and IT Ops has the reassurance that the right infrastructure resources are being consumed.

Automatic Updates: With semantic versioning of boxes, customers can now choose automatic updates for major, minor and patches of instances. This enables rapid, efficient updates at scale for enterprises.

Enhanced Container Support: As more customers experiment and deploy to containers, ElasticBox can now support containers, such as Docker, as a new box type. This enables enterprises to define microservices as Dockerfiles in containers, which then can be linked via bindings. With this enhancement, the lifecycle of application services can be easily managed.

vCloud Air and vCloud Director Support: ElasticBox supports a multitude of private and public cloud infrastructure providers. Enterprises with VMWare’s vCloud Air or vCloud Director workloads can now leverage ElasticBox for complete workload automation. At deploy time, ElasticBox auto provisions vApps, one template per VM, and orchestrates automation.

I had a chance to speak with Carol Carpenter, CEO of ElasticBox on the new release:

Q. Why is this latest release so important?

As DevOps matures, we see that companies seek to not only provision applications faster but reduce inter-dependencies between development, QA, and IT Ops. Kill the cruft in the application cycle.

This latest release of ElasticBox brings deployment policies for DevOps to retain needed control and visibility while enhanced container support delivers more flexibility to application teams.

Q. What’s changed?

Many enterprises have built their application deployment workflows around a handcrafted potpourri of tools and processes. When faced with scale challenges from the business, existing tools are fragile and expensive in terms of failed builds and troubleshooting time. ElasticBox brings an adaptive off-the-shelf management solution so enterprises can spend less time re-tooling and more time shipping code.

Q. What’s next?

ElasticBox is built by developers who want to ship code faster to the cloud, and we’re committed to this mission. We’ll continue to ensure our platform adapts to customers’ evolving environments, regardless of which technologies they choose for their development and operational stack.

More information on the new release can be gleaned from ElasticBox CTO Alberto Arias Maestro’s blog.

devopsy.kinsta.cloud is working with ElasticBox on a new DevOps survey right now. You can take the survey and win an Amazon Gift Card or 3dr Drone by taking the survey here.

June 29, 2015
Visualizing and defining requirements comes to DevOps

We have all seen the nice circular diagrams of a DevOps methodology for application lifecycle management (ALM) like the one above. We interject some automation, make the two halves work closer together, get some feedback loops going and go as fast as we can. But lets look at those first two steps in the diagram, the ones labeled consult and design. What and how do we accomplish this? There is a company called iRise that has built a great business by allowing for rapidly visualizing and defining requirements for building applications. It is high time we recognize this as the important piece of the puzzle that it is.

I recently had a chance to meet with some of the executive team of iRise while I was in London for the CD Summit. The premise of iRise is so simple I was thinking to myself, “why hasn’t anyone else thought of this?” If the old adage of crap in is crap out is true, why wouldn’t we take the time to define and plan our software better early on? I know everyone thinks they do, but do they really? Do we quickly visualize to help define the requirements and to help the team buy in and sign off? If it is set up right to begin with, it flows a lot faster later.

Now the folks at Tasktop creators of the Eclipse Mylyn open source tool have teamed with iRise to OEM iRise into the Tasktop Software Lifecycle Integration system. In speaking with Stephen Brickley, EVP of iRise, he thinks this partnership will be a key factor in bringing iRise into the mainstream DevOps tools market.

iRise’s customers, like software departments everywhere are adopting new ways of developing and operating software. New times and new ways don’t mean that you throw out what works though. To me it is a no brainer. If you have a tool that lets you quickly visualize, prototype and communicate to the rest of the team before investing a lot of effort into development, it really has to help. It is the ultimate shift left.

I guess the issue is how quickly can you do this without adding extra steps to the development process. From what I saw of iRise it makes it really easy and fast. Of course I would be interested to hear from anyone who has used iRise or even a similar tool on your own experience. But if it all is as it seems, I would expect iRise to be a welcome addition to the DevOps toolbox.

What do you think? What tool do you use for this now or do you just skip this in planning and initial requirements? We are always on the lookout for new tools to report on at devopsy.kinsta.cloud, but ultimately we depend on our readers to tell us what is really useful or not. So let us know.

June 26, 2015
Rancher Labs hopes to help DevOps teams rope in container management

DevOps teams have turned to containerization in a big way in order to help improve their efficiency. But many enterprises have run into problems scaling containers across their infrastructure to account for issues like networking and load balancing.

Rancher Labs, a Cupertino-based cloud software startup, is hoping to help organizations address the scalability with a new open-source Docker platform. Eponymously dubbed Rancher, the beta version for the platform went live this week. It’s designed to be a full set of tools to help DevOps teams manage Docker containers in production. The platform folds in infrastructure services built specifically for containers, including networking, storage management, load balancing, service discovery, monitoring, and resource management.

The goal of containers is efficiency and full portability, but Sheng Liang, co-founder and CEO at Rancher Labs, notes that the implementation can be hard to get perfect.

“As users deploy containers across different infrastructures, they quickly realize that different clouds, virtualization platforms and bare metal servers have dramatically different infrastructure capabilities,” said Liang. It’s these variables that Rancher seeks to limit. “By building a common infrastructure backplane across any resource, Rancher implements an entirely new approach to hybrid cloud computing,” said Liang.

The company is going long on containers—an assessment that backers agree with. The company also recently announced that it has received $10 million in series A funding from Mayfield and Nexus Venture Partners. In addition to its Rancher suite, the company also produces RancherOS, a minimalist Linux distribution tightly focused on running Docker containers.

The management team behind Rancher is one that is familiar to many cloud practitioners. Co-founder and CEO Sheng Liang was co-founder and CEO of Cloud.com, and continued on at Citrix as CTO of Cloud Platforms Group after the company’s 2011 acquisition. Also on board are Cloud.com and Citrix veterans Shannon Williams as vice president of sales and marketing, Darren Shepherd as chief architect and Will Chan as vice president of engineering.

According to industry analyst Paul Burns, Rancher Labs’ niche is ripe for new innovation.

“In its current state, running any containerization solution at scale and in production requires a significant amount of effort from those adopting the solution,” says Burns, who is president of analyst firm Neovise. “Key functions such as networking, service discovery, storage and load balancing can cause integration issues, keeping enterprises from truly reaping the benefits desired. By providing a unique solution that eases and simplifies the management of container software, Rancher is allowing companies to better utilize and benefit from the technology.”

June 25, 2015
How ITIL Can Co-Exist With DevOps
The original ITIL framework definition was published in the 1980s, but contrary to many opinions, it has evolved since then, provided one takes a more flexible view. Fast forward to ITILv3, and the framework has been shifted to the view that IT is a service that needs to support business initiatives and strategy.

In parallel, the “DevOps Movement” has continued to gain momentum, and is now the “culture” at many forward-thinking organizations. So, that begs the question, “Can I have my ITIL framework and still transform my IT Org to embrace DevOps?”

First, as a refresher, let me quickly outline the key components of ITILv3.
1. Service Strategy — The service lifecycle must stay focused on meeting the business goals and objectives.
2. Service Design — Architectural blueprint for the service
3. Service Transition — Outlines the change management and release cycle practices
4. Service Operation — Focuses on the delivery and control processes for the service
5. Service Improvement — Focuses on how to continually improve the processes for Service Delivery
Now let’s lay out an engagement model for the transition of the culture to DevOps.
1. DevOps Strategy — Establish metrics that outline Business Objectives and Value
2. DevOps Design — Establish Capacity, Availability, and Security Best Practices
3. DevOps Transition — Establish Organizational Structure and Define SLAs
4. DevOps Operation — Shift to Agile; Programmatic CMDB and Change
5. DevOps Improvement — Automate Incident, Problem, and Event remediation; Feedback loop
As you can see, there isn’t a huge gap between the two worlds, and I assert that the main changes are cultural, not technical, but one can use technology to start shifting the culture.

This is where the concept of a Security Fabric plays an integral role. Here is an example of how an Enterprise Reference Architecture can be organized to combine the best parts of ITIL and DevOps:
1. Policy Definition — Allows you to define Users, Groups, Hosts, Layers, and Interdependencies
2. Secrets Management — Allows you to store Secrets in a vault and access them programmatically in a secure manner with a complete Audit Log
3. SSH Management — Allows you to securely manage SSH public-keys and session interaction with a complete Audit Log
4. Host Factory — Allows you to instantiate and register new hosts or containers into your infrastructure
5. Identity/Service-Defined Authorization– Allows you to control interaction between your hosts or containers via Policy and Gatekeeper
IT now has a powerful platform to map Business Objectives to Identity, Hosts, and Processes. Once that mapping is established, previously static and brittle activities such as managing Secrets and SSH public-keys, can be moved into the Continuous Delivery pipeline, which maps directly improving Service Transition, Operation, and Continual Improvement.

Agility and Scale are programmatically added via various tools, which allows for frictionless and auditable Change requests, as well as rapid response to Incidents, Events, and Problems.

The diagram below attempts to pictorially show the co-existence of ITIL and DevOps and how the features of a Security Fabric are common between the two.

The shift to a DevOps culture should be approached as a continual evolution. ITIL was a great starting framework, but over time added too much structure and rigidity. You can leverage the Best Practices of DevOps to overcome that and transform into an extremely agile and productive environment.

About the Author/Mike Kail

Mike Kail was Yahoo’s CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly scalable architectures, prior to joining Yahoo. Most recently, Kail served as VP of IT Operations at Netflix. Prior to that, he was VP of IT Operations at Attensity, where he was responsible for the Americas data center operations team; including managing various big data systems with their Hadoop cluster, HBase, and MongoDB components. He has been recognized widely for his insightful industry commentary on Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” He holds a B.S. in Computer Science from Iowa State University. Reach out to him on Twitter or LinkedIn.
June 24, 2015
Choosing a Mobile Test Automation Solution: What You Need to Know

Organizations today rely more and more heavily on mobile apps to drive their business. In fact, many companies are already seeing more than half of their web traffic coming in via mobile devices. In some cases, their mobile app is the only way customers interact with their products.

It’s no surprise, then, that developing, testing, and releasing quality mobile apps quickly and efficiently is a high priority for most organizations—as it should be! Fortunately, mobile development tools are evolving to meet these needs, with modern dev teams having access to better test automation than ever before.

Of course, the effectiveness of a mobile testing process is only as good as the technology behind it. This makes it even more crucial for organizations to know what factors are most important to take into account when choosing or building a robust mobile testing solution. Below, we outline some key things to consider:

Native, Hybrid, and Mobile Web Support
Modern mobile applications come in three different flavors: native, hybrid and web. Native apps are built using the vendor-provided SDKs. Hybrid apps run some or all of their functionality inside a webview embedded in a native app. Finally, mobile web apps are simply mobile-optimized website that users access through their mobile browsers. While there is a growing trend towards mobile web and hybrid applications (rather than native), to ensure maximum flexibility and impact of your QA solution, it’s important that you choose a tool that supports all three kinds of apps.

On-Demand Cloud Testing
With QA teams becoming more and more distributed, it makes sense to ensure that your mobile application testing solution includes a cloud component. Leveraging an automation cloud enables teams to use organize around a single implementation of test architecture, with devices and test result data accessible from anywhere in the world. You can spend your time worrying about your testsuite, not the cost and maintenance headaches associated with keeping up multiple home-grown device grids and architectural patterns.

Automation
When it comes to mobile testing, automation is essential. Choosing the right automation frameworks (Selenium, Appium, etc…) and test tools (languages, test runners, etc…) can be a challenge, and it’s important to think about all the factors involved in getting a solid mobile build process going, relative to the expertise your QA team possesses. What kinds of user flows will you need to automate, and can the automation tool support them? Do you want automation code mixed in with your app code or cleanly separate? Is automation support available for the languages and tools you know best? Think about building a testsuite with the same level of architectural foresight as you would building an app.

Integration with Key Support Systems
It’s also important to consider what level of integration is needed with support systems in your environment – whether it’s a test management system, a CI server, or defect tracking system. A strong solution will be able to easily integrate with all of these other systems, perhaps all the way down to the IDEs your developers are using.

Cross Platform Support
With the majority of applications being developed for iOS and Android, it’s a minimum requirement for your mobile application testing solution to support automation on both platforms. Of course, this will no doubt expand as you consider other devices and operating systems such as Windows, FirefoxOS, etc…, based on your customer base.

Scalability
As the number of device types and operating systems being tested increases, it becomes increasingly important that your test architecture is able to scale automatically based on the number of tests you want to run and the amount of time you want your build to take. Building your automation on a framework like the open source Appium project is a good architectural investment; Appium’s client/server architecture makes it easy to build a testsuite than can automatically utilize a cloud service as your need for more emulators, simulators, and real devices grows.

The proliferation of web and mobile applications across a myriad of devices and operating systems is fueling a demand for faster and faster delivery of software experiences, without any sacrifice of quality. Today’s leading software companies know that successful apps are built on the foundation of their mobile application testing processes and tools. By keeping in mind the key features mentioned above, organizations can work towards building and identifying the best testing solution for them. The QA process should be a breeze, rather than a hassle.

About the Author/Jonathan Lipps

Jonathan Lipps serves as the director of ecosystem and integrations at Sauce Labs, where he leads a team of developers to ensure that the open source ecosystem surrounding the company’s core products is always maintained. He is a frequent speaker on automated web and mobile app testing, and holds advanced degrees in Linguistics and Philosophy. Reach Jonathan on twitter.

June 23, 2015
Software Development of the Future: Partnering with Outside Sources How One Company Found Success with Outsourcing a Major Project

Untangle develops and designs security software and appliances that protect computers and enterprise networks. By synthesizing enterprise-grade capabilities with consumer-oriented simplicity, our company creates products that are both powerful and intuitive to use. Designed for organizations ranging from small schools and businesses to large campus environments, our open source solutions offer a cost-effective alternative to expensive, inflexible proprietary software.

In 2007, we were at a crossroads in our software development efforts. We needed to implement a major technology upgrade without delay, but didn’t have internal resources to support the project. The technology at the core of our firewall application with desktop user interface was becoming obsolete, and we needed to replace the existing Java Swing-based user interface with one that was web-based. Building a new UI was not just a massive project; it was a crucial one as well.

The Untangle Next Generation Firewall includes both free and paid apps that block unwanted content, spyware, and viruses from networks. Our Internet Content Control product gives users insight into and control over all their Internet traffic for optimal Internet performance. The usability of the Untangle Firewall was one of the product’s most distinct features. Many of our customers were small businesses and academic institutions with users who were not technical experts, so our management team had to ensure that the new UI delivered the same intuitive user experience as its desktop predecessor.

To take on development of the new UI, we needed to dedicate a new team of software developers for well over a year. Building a development team based in Silicon Valley was impractical in terms of both cost and availability. Competition for top technical expertise was fierce in Silicon Valley and, as a result, compensation levels were skyrocketing. We ended up selecting Gemini Solutions for the project because they were capable of performing highly complex development work and also had capabilities working with JavaScript libraries, a key requirement of the UI project.

The Untangle Firewall with its new, web-based UI was launched 18 months after definition. The new browser-based product was a resounding success with our customers. Some firewall products completely ignore usability, but we’re passionate about it. Gemini’s expertise with JavaScript made it possible to replicate the user experience while entirely changing the underlying technology.

Today, Gemini continues to manage the migration to new JavaScript libraries and supports Untangle with other ongoing software development projects as well. These days, JavaScript libraries are very fancy and, as a result, every migration is a big complex project requiring deep knowledge. Gemini has unsurpassed expertise in this area and maintains ownership of that portion of our development.

The best advice I can give a company looking for outside software development support is to find an organization worthy of their trust and then to trust them fully. Talented individuals want to be an integral part of the team, and they deserve to be. I would highly recommend looking to outside support when you are working on major products. Make sure that they are a good cultural fit, aren’t passive and aren’t afraid to push back. You want a team that will take initiative and offer suggestions. That’s an element that’s missing in so many outsourcing arrangements, so it is important to do your research before selecting a firm.

About the Author/Dirk Morris

When he’s not summiting El Capitan or off-roading in Baja, Dirk Morris spends his time as the founder and engineering visionary behind the Untangle network gateway platform. Prior to Untangle, Dirk was Chief Architect at Akheron Technologies, where he invented the patent-pending High Bandwidth Transparent Vectoring used in the company’s proxy firewall engine. He has also held positions as lead engineer at VerticalNet and H.L.L.C. Consulting, developing Java-based distributed monitor and intrusion detection systems. Dirk earned a Bachelor’s degree in Computer Science with a minor in Mathematics from Carnegie Mellon University. He worked on survivability simulations at CERT/CC (Computer Emergency Response Team), the University’s renowned, federally funded Center for Internet security.

June 10, 2015
SQL lovers fear not – NoSQL just got friendlier

Today Couchbase, the creator of an Enterprise NoSQL database server, announces N1QL ( pronounced Nickle) at their user conference. N1QL is designed to ease the pain for SQL developers when considering NoSQL, by creating a new query language to sit on top. It is essentially SQL for JSON documents.

(more…)

June 3, 2015
5 Ways To Speed Up Mobile App Testing
We’re all familiar with the story of the tortoise and the hare, where a plodding tortoise wins a race against a speedy hare because the over-confident hare takes a nap midway through the race.

It’s a valuable lesson about the power of smarts over sheer speed. But all due respect to the methodical approach, the tortoise does NOT win the race in mobile app testing. The hare wins. But he needs to be smarter than Aesop’s reckless rabbit.

Despite efforts to expedite app release cycles, enterprise mobile teams still struggle with what we call “velocity blockers”, which are testing practices and processes getting in the way of fast, iterative app releases. To get to the bottom of velocity blockers, the Perfecto Mobile research team surveyed a group of 350 enterprise-level developers, DevOps and QA people of various responsibilities about what testing-related issues are slowing them down.

The survey data revealed an encouraging shift to Agile practices that emphasize quick results and integrated feedback. It’s like having a hare’s body with a tortoise’s brain. Of our respondents, 86% said that they’re either Agile, or have made the first steps towards Agile. And 94% say they’ll be there within a year.

This shift is reassuring, but testing lags remain in the way of progress, according to survey results. Here are the five main velocity blockers cited by respondents, with tips on how to be smart like a tortoise while moving as fast as a hare.
1. Slow QA to Developer Feedback
As developer teams begin using agile practices, the feedback loop between QA and developers tends to be unbalanced. Often when a company speeds up to a monthly release cycle, a team will spend three weeks developing and the last week testing and fixing bugs. The problem here is that as much work needs to happen in the final week as in the previous three weeks.

Solution: We recommend embedding quality throughout the entire lifecycle, a concept we call Continuous Quality. QA feedback is always visible and developers always know where their code stands because it’s constantly being tested. Maintaining this kind of control over the quality of your mobile app throughout all stages of your SDLC will boost the speed of development and reduce the number and severity of defects reaching production.
1. Ineffective Test Automation
Automation, on its own, may speed up testing and releases. But it’s how automation is implemented that really makes a difference. Automating your test scripts is an important step, but it’s not enough. You must first make sure your environment is stable for automated tests. When you run automated testing across an unstable environment, false negatives happen.

Solution: Start by automating the provisioning of your test environment to make sure it’s stable and will support your test automation correctly. If your environment is stable, your tests won’t return false negatives.
1. Delays in Device Readiness
Was your app ready to run on the Samsung Galaxy S6 when it released? Did someone on your team wait at the store to purchase it so you could deliver 0-day test results? Better yet, did you get it before it was released to test your app against it before users could upgrade? The answer is probably no, just based how quickly new devices are released to the market. But to maximize test coverage, device readiness is a full-time job. So how do you get the latest devices into your test lab, online and ready for testing before your users are impacted?

Solution: Let a managed lab-as-a-service do some work for you, where a vendor acquires new devices, maybe before they’re publically available. Let them manage your test lab for you, and dedicate experts to you. Make sure they also offer an SLA. It costs an estimated $6,500 per device per year to manage in-house. Multiply that number by the total devices you need to test on, and this gets unscalable, unmanageable and unprofitable.
1. Slow Access to Mobile Devices
Let’s say you do buy devices and manage your own lab. The next issue you’ll run into is making those devices available to your testers all over the world in real time.

At one of the top U.S. mobile carriers, when a new device was released, the carrier had staff who had to acquire the device and ship it to where testing was performed. This group had limited time to test the device before shipping it to another testing group. When timelines weren’t being met, the staff member physically traveled with devices, from test group to test group, to ensure they made it into the right hands and on time. Travel costs made for an inefficient process.

Solution: Once the carrier chose to put devices in the cloud, the device procurement and deadline challenges were eliminated and a scalable, on-demand cloud emerged. They can now centrally manage devices for testing via the cloud and groups can access devices remotely while still ensuring the same user experience.
1. Manual Testing Takes Too Long
Manual testing is by far the top app development velocity blocker. We work with a lot of the major banks because, more than most industries, banks win and lose customers on the merits of their mobile app. One of the top U.S. banks came to us back in 2010. They were doing lots of manual testing of a wide range of complex scripts. It took them a long time to push through their test cycles, and app defects were missed.

Solution: The bank’s pre-automated test environment relied heavily on manual testing, and included duplicate labs and a 16-20 day regression cycle. After automating their testing scenarios, they saw a 90% time reduction per regression cycle. That’s bringing weeks-long cycles down to mere hours. They were even able to quantify that they saved $40,000 per test cycle. In the end, the bank was able to decrease their cycle times and the defects released to production by doing test automation. A major velocity blocker was unblocked!

About the Author/Eran Kinsbruner

Eran Kinsbruner, is director of product marketing at PerfectoMobile, one of the leading mobile cloud and automation companies. Formerly CTO for mobile testing and Texas Instruments project manager at Matrix, Eran has been in testing since 1999 with experience that includes managing teams at Qulicke & Soffa, Sun Microsystems, General Electric, and NeuStar. The co-inventor of a test exclusion automated mechanism for mobile J2ME testing at Sun Microsystems, Eran has experience in the mobile testing world. You can find Eran on Facebook, Twitter @ek121268, LinkedIn, and his professional mobile testing blog at ek121268.wordpress.com.
June 2, 2015
IT Asset Management: How to Find Out if Your Database is Causing Performance Problems

As your IT infrastructure grows, it becomes increasingly important to be able to identify where bottlenecks, performance problems, or outages are occurring so that you can quickly act to fix any issues. Identifying the source of a problem can be a bit tricky once you have grown into having multiple apps, servers, and databases—but there are tools that can significantly ease your burden in locating where an issue has arisen.

The Problem: Identifying the Source

The end user experience is affected when services are not functioning properly. Source: http://logicalread.solarwinds.com/response-time-analysis/#.VWNncfm4TIU

Often, IT infrastructure begins on a small scale. Perhaps you start with a single app that runs on a single server with one small database. At this point, it is usually fairly easy to determine if that server is down, since everything will simply stop working. If it is simply the database itself, the app will most likely return errors connecting to the database.

At this level, you likely won’t feel any urgent need to set up a more robust form of monitoring. After all, there are only so many things that can go wrong. However, as your services grow, managing those services in an efficient manner becomes increasingly important.

Once you begin having multiple apps, servers, or databases, you will find that keeping track of issues becomes more time-consuming and difficult, since it may not always be clear what part of the system is failing. For example, if you have two apps using the same database server and both are not responsive, you will need to determine whether both app servers are down or the single database server is down. This could require checking in several different places to ensure you identify the correct cause.

The Solution: Using a Monitoring Service to Manage Your Services

A monitoring service can quickly show you if you have any problems. Source: http://www.happyapps.io

Time to resolution is important when diagnosing and fixing any downtime for your services. You can save yourself quite a bit of time by having your various services monitored. A monitoring service cannot only send you alerts when things go wrong, but can specify which service is misbehaving or down.

For instance, if your database server has crashed for some reason, you are alerted immediately and know exactly where to go to fix the issue. If you have multiple database servers, this is even more valuable, since you will know which one it is without looking at each server until you find the one that is in error.

With a monitoring service like Happy Apps, you also get to tailor the alerts to suit your needs most effectively. You can choose to have notifications arrive by e-mail, text messages, or push notifications to your mobile device. You can also limit your alerts if needed, so that you receive only messages when there is a critical issue as opposed to something being temporarily slower than normal. Incidents are automatically opened whenever a check fails, and once all checks in an incident are passing, the incident will automatically become closed. You can always drill down to a specific incident and view the details (i.e. issues, history, and members), and Happy Apps tracks your incidents so you can understand how you fixed previous problems if the incident were to arise again.

So, why not setup your services with Happy Apps? The configuration process, often a time-consuming challenge, is made incredibly easy with Happy Apps: with just a few clicks and less than 60 seconds Happy Apps checks are watching your services. Furthermore, in DevOps style, there is an API to add checks as well. The time you save yourself in identifying where problems are occurring will make you and your end users happy!

May 28, 2015