devopsy.kinsta.cloud

Tag: technologies

  • UK technology firm Cloudhouse sees three-fold revenue growth and expansion into the US

    Appoints Nick Coleman as CTO, and outlines its strategic growth plans

    London, UK – October 16, 2018 – Cloudhouse Technologies has seen over 300 per cent growth over the last 12 months, and expanded its business into the US – thanks, in part, to strategic partnerships with Microsoft and Amazon. As it looks to continue its growth and expand its global footprint, Cloudhouse has also appointed Nick Coleman as CTO.

    The company, which developed the innovative ‘Compatibility Container’ system, enables organisations to continue using their legacy applications safely and securely on new platforms and within the cloud without any code changes, even when they’re designed to run on unsupported versions of Windows and Citrix.

    This is because ‘containerizing’ legacy applications resolves the problems around running 32-bit Windows XP and 7, Windows Server 2003 and 2008, and Internet Explorer-based applications on modern secure and supported operating systems and platforms. In addition to reducing the risks associated with unsupported operating systems, using a Container approach also helps eliminate costly Extended Security Update agreements and can help further reduce operating costs by consolidating server infrastructure.

    Cloudhouse has recently expanded its operations into the United States and started to build a team in the region. Coleman’s appointment as CTO frees CEO and founder, Mat Clothier, to focus on the company’s growth plans, including those in the US market and other Global markets.

    Previously head of application management at Sopra Steria and vice president, technology, at CGI, Coleman brings a wealth of experience in service delivery and of working with customers who rely on Microsoft-based products. He will focus on developing Cloudhouse’s technology offerings, as well as looking at innovative ways to support its growing customer base.

    Nick Coleman, CTO, Cloudhouse, said: “Having spent the last 20 years delivering enterprise services, I understand the huge challenges organisations face when it comes to legacy applications. Thanks to our technology, along with strategic relationships with Microsoft, Amazon and Citrix, our product is uniquely positioned to help clients mitigate risk and move legacy applications to a more cost-effective, modern and secure environment.”

    Mat Clothier, CEO and founder, Cloudhouse, said: “This is a key time for Cloudhouse as we continue to grow our customer base and move into the US market. We’ve experienced significant growth as we work to support more organisations and bigger customers to mitigate the issues of legacy operating systems. Nick’s appointment will go a long way to support this momentum, and his experience with Microsoft users and service delivery will boost our offering – and means we can continue to create solutions that help customers use their preferred applications safely and securely, no matter what their age, original operating system or browser specification.”

    About Cloudhouse

    Cloudhouse Containers free enterprises from running unsupported Windows and Citrix platforms by making otherwise incompatible applications run on the newest platforms – whether they run on premise or in the cloud. Apps only need to be packaged once in stateless containers that handle application runtime, isolation, and full redirection. As a result, enterprises can complete Windows 10 or Cloud migration projects successfully. Cloudhouse is based in London.

    For further information,

    Visit: https://cloudhouse.com/resources/announcing-three-fold-revenue-growth

  • Get Your DevOps Right With These 7 Technologies

    Get Your DevOps Right With These 7 Technologies

    Editors’ Note: As with all of our contributed articles, the views expressed in this article are of the author, not devopsy.kinsta.cloud. Due to its vendor-agnostic stance, devopsy.kinsta.cloud does not endorse any particular technology.

    There was a time when the operations team and the developers regularly were at each other’s throats. The developers were never satisfied with production code updates and the server administrators chafed at developers piling up the serve requests and circumventing the processes.

    However, the battle lines have been somewhat erased since the advent of DevOps. IT teams adopting DevOps can move rapidly from concept to production to enhance the business impact, quality and velocity of the application delivery. Many organizations are shifting to DevOps because of its high efficiency and the number of people taking DevOps training are also increasing due to numerous job opportunities in this field.

    DevOps Technologies to Know

    A number of technologies have emerged to help in the shift to DevOps, providing services ranging from the configuration management to application portability. Following is a list of seven technologies worth noting.

    Splunk

    Splunk is used for detecting and fixing issues across the life cycle of an application in real time. It allows the developers to see data from the production environments, eliminating the need to access production machines. Splunk enables DevOps processes including continuous integration and deployment.

    The Splunk platform is used for DevOps to:

    • Provide end-to-end visibility across each and every component of the DevOps tool chain.
    • Utilize the objective metrics to make sure the code meets the quality SLAs and is operational.
    • Correlate the business metrics with changes in code to obtain new business insights.

    ScriptRock GuardRail

    ScriptRock Guardrail is designed to rapidly pinpoint the differences in configurations on desktops and servers, comparing the states between systems and over time. ScriptRock Guardrail shows what has changed, helping simplify diagnostics and decreasing downtime.

    Developers who work with agile methodologies are accustomed to a test-first way of working with the unit tests, making sure that everything works as planned. As continuous delivery becomes more prevalent, the DevOps and Ops teams need to take a similar approach. This is where the ScriptRock GuardRail comes into its own, providing you the tools to construct and build infrastructure level unit tests and view the results visually, thus making it very easy to rapidly drill into the real problem and get your services running.

    ScriptRock GuardRail focuses on addressing the key prerequisites to any DevOps, and, more precisely, initiative and automation. They are described below.

    • Visibility: The GuardRail platform delivers visual configurations showing differences between like devices, configuration drift monitoring and automated visualization and scanning of network device and server configurations.
    • Accountability: Users can curate and filter configurations to generate policies that can be utilized to ratify the configurations on a continuous or ad hoc basis.
    • Automation: All the policies can be exported to Windows PowerShell DSC, Docker, Ansible, Puppet and Chef.

    ScriptRock GuardRail works with any automation tool and can be delivered as single-tenant SaaS, multitenant SaaS or a virtual appliance on-premises.

    SaltStack

    The SaltStack Enterprise Software helps DevOps organizations by organizing the systematic motion of code into production by maintaining the complicated infrastructures refined for optimal application delivery and business service. While DevOps is not a tool, it requires a tool-centric approach to enable continuous delivery. SaltStack helps to configure as well as quickly deploy the dynamic applications and general-purpose infrastructure they run on. DevOps is gaining wide popularity around the world because of the tools like SaltStack that enhances its efficiency.

    SaltStack is a cloud infrastructure tool and delivers the systems management for application configuration, cloud building, server provisioning and data automation. It is an event-driven tool and can automate the tasks within DevOps workflow and makes the operations highly approachable for the developers. SaltStack provides a common language and common way to manage the servers and thus helps to bridge the gap between Devs and Ops.

    Puppet

    Automation is the foundation for many DevOps practices. It is the key to continuous delivery and faster deployments. Automation imposes consistency across the production, testing and development environments. It makes sure users can rapidly orchestrate the changes throughout the infrastructure: container and cloud deployments, virtual machines and bare-metal servers.

    No matter where it runs, Puppet provides a standard way of operating as well as delivering a software. Users define what they want their infrastructure and apps to look like utilizing an easy-to-read common language. From there, they can enforce, test and share the changes they want to make across their data center. Reporting and visibility is available at every step of the way to help prove compliance and make decisions.

    The Puppet Enterprise enables users to test changes before deploying them to production. With Puppet Enterprise, the infrastructure is defined as code, which enables users to adopt the best practices of agile development including automated deployment and testing, and deliver the software more reliably. This is because the configurations are consistently promoted, shared and tested across all environments, from Dev laptops through test to production.

    Atlas

    Atlas was the first commercial product released by HashiCorp, provider of open-source tools that enable the efficient deployment of software-defined applications and data centers. Atlas provides visibility into the infrastructure, including virtual machines, containers and servers, in addition to service discovery and configuration management. Building on the popular open-source projects of HashiCorp such as Terraform, Consul, Serf, Packer and Vagrant, the closed-source proprietary Atlas enables DevOps across different cloud services, which include OpenStack, Azure, Google Compute Engine and AWS, and provides a dashboard for maintaining, deploying and developing applications.

    Many engineers are shifting to Atlas today for their organizations’ customer engagement platforms. Atlas brings it in one place and enables the companies to handle end-to-end starting from configuration management to container deployments across various cloud environments. Every open-source tool is fine alone, but the capability to handle and orchestrate them as a whole is extremely powerful.

    Chef

    Chef is a cloud infrastructure and systems framework that automates the management, deploying and building of the infrastructure via repeatable, short scripts known as “recipes.” But the actual strength of Chef lies in its utilization of the pluggable configuration modules(also known as cookbooks), about 2,000 of which are available through Chef community. Facebook, the high-profile user of Chef, recently open-sourced few of its own Chef cookbooks, which include its Grocery Delivery and Taste Tester testing framework, which watches a source code repository such as Git and keeps the local Chef server in sync.

    The complex tasks are automated by Chef that are otherwise resource- and time-intensive. But, more importantly, Chef allows users to focus their efforts on improving and innovating the quality of their services. It also opens the door to more efficiency and collaboration across the organization.

    Docker

    Through its containerization technology, Docker brings portability to the applications wherein the applications run in self-contained units that can be moved across the platforms. It consists of Docker Hub, a cloud service for workflow automation and application-sharing and Docker Engine, which is a lightweight packaging and runtime tool.

    Docker has revolutionized the containerization of applications enabling DevOps to package any kind of application in a lightweight environment. The packaging is done in a way as easy as installing a mobile app. Docker is considered as the most popular DevOps tool. By using docker, the developers can containerize their apps and can run them anywhere. Built on top of Linux containers, docker is a powerful ecosystem where DevOps can use many apps (available on Docker Hub) to the maximum advantage.

    About the Author / Savaram Ravindra

    Ravindra was born and raised in Hyderabad, India, popularly known as the ‘City of Pearls’. He is presently working as a Content Writer at Appmajix Technologies. His previous professional experience includes Programmer Analyst at Cognizant Technology Solutions. He holds a Masters degree in Nanotechnology from VIT University. He enjoys spending time with his friends. He can be contacted at savaramravindra4@gmail.com. Connect with him also on Twitter and LinkedIn.

  • Technology is All About the Business

    Technology is All About the Business

    In 2011 I joined a company as their fifth employee. They had been in business a little over a year. They had a product. They had customers. Oh, and the other four people? They were rockstars.

    Customers, however, were unhappy. The system was frequently down. Rebooting a machine was often necessary and lead to poor performance for hours.

    I was hired to fix “the database problem” in a multi-tenant SaaS system. On my first day I was given a tour of the technology by the engineer. The code was immaculate, but the database had some core issues. We had the database in good working order in a couple of weeks. We lost our first customer about two weeks after that.

    Why did this customer leave? Ultimately because we were not working on the problem that mattered. We created a local optima in the database and another in code quality. It turned out that there were more fundamental problems.

    Achieving local optima is a false economy. (1) We needed to think outside our core skill sets. Systems thinking pointed the way.

    The Reaction that Mattered

    We had three months cash left. We had two months until our make-or-break event. The business closed a sale for two months operating capital! The customer was a very big brand whose needs would stress the existing software beyond its limits.

    At this point the problem that mattered was immediate and clear. How do we guarantee this customer’s success? As with many things, the answer was obvious once we thought of it: We stood up a duplicate of the production software just for them.

    The Patterns we Recognized

    Standing up a second production environment was no easy task. Over 200 bash commands lovingly executed across five hand-crafted cloud servers. It took days to get our bespoke second system stitched together.

    While it was ideal that we landed such a big contract, the truth of the matter was the business was not confident in our product’s technology. For each potential sale after landing the big one, I would get a call, “Are you sure we can handle this next customer?” The answer was already apparent. We, the tech team, were not confident either.

    Changing the Software

    We needed to improve the software so one customer’s activity had no possibility of impacting performance for another. This would localize problems to a single customer and increase the business’ confidence. We needed to do it quick. We needed to do it with a single engineer and DBA.

    Each customer would get their own full copy (share nothing) of the software. Deployment of the software would be reduced to the simplicity of stamping out parts in a factory. With this model we rewrote the system and closed three new customers on it for our big event.

    Moving to this “share nothing” paradigm is likely the single biggest contributor to the company staying in business, thriving and eventually being acquired. The confidence of the sales force increased dramatically. Sales increased dramatically. Our runway moved out past the six month mark.

    Why Share Nothing

    We recognized our system was a B2B offering, not B2C. This a type of pivot know as a business architecture pivot. (2)

    Trying to build all of the infrastructure for a self service system that scales to unknown demand, while really cool, was not the problem we needed to be solving. Yes, there are inefficiencies in such a share nothing system. No, none of them impacted our bottom line.

    For example, we didn’t care that we were wasting compute. The price of the compute was built into the product. The customer was not paying for compute. They were paying for the product and they were willing to pay so much that this cost didn’t matter.

    Powerful Consequences

    We effectively rewrote the original system in two months. This still seems miraculous, and to some extent it is a testament to the amazing quality of the business logic code. There were, however, other consequences to the “share nothing” model that gave us a significant, if temporary, market advantage.

    • We had no need to spend engineering cycles on plumbing such as user management.
    • We had no need for a billing system. Human-time invoicing in a B2B world was plenty effective.
    • We had no massive scale of data or load. We used familiar technologies.
    • When an instance went down, only one customer called. We learned most of these things were training issues.

    For each item above, the need for engineering was eliminated or dramatically decreased. This means the engineer used that time to create new features. More features means more revenue if you are building the right things. Our CEO and founder was a genius; we were building the right things.

    And it Broke

    Sales trusted the system. New customers were coming in. Existing customers were happy. Infrastructure costs decreased.

    It was short lived. The tools and technology used to implement the repeatable, “share nothing” software were not up to the task. The success of sales was creating a new problem, though a much nicer one to have! We needed more systems thinking.

    Did DevOps Fail

    We did not initially choose the right tool. Is this story a DevOps failure? If you subscribe to the idea that process informs tool choice, then the answer is a surprising, “No.” The DevOps thinking was sound, we simply need to choose better tools to support the model we had chosen to implement. Technology is all about the business at the end of the day.

    Part Two of this case study will highlight some of the evolution of the tools and processes we put in place that lead us to further success.

    References

    (1) The Goal – Eliyahu Goldratt, Jeff Cox
    (2) The Lean Start up Eric Ries