devopsy.kinsta.cloud

Tag: container

  • It’s Funny How We Forgot About Container Sprawl

    It’s Funny How We Forgot About Container Sprawl

    …Because it sure as heck did not forget about us.

    We are (thankfully) past the days when everything was a container. At least, most of us are. Just like anything else, some orgs will continue that approach for reasons both great and terrible. And all of us still use far more containers than we need, I would say. “One container, one function,” works if you are talking about one whole application, and maybe sometimes for busy parts of an application, but it certainly isn’t needed to host a couple of low-use APIs, for example. My favorite example is separate instances of the same exact application for different teams (not business units – that is a good method to separate business units).

    Thankfully, technology is once again saving us from ourselves and our misdeeds. Processing power is no longer an issue, meaning we can spin up a million containers and keep them running until our public cloud bill arrives. So, it’s not about processing power. I cannot remember the last time that an org was bandwidth-limited, so it’s not about the network. The biggest issue is still security. More containers means a bigger footprint, which inevitably creates more vulnerabilities. Right behind that is container inventory management. What is running where, what images are available and what state are they in, which running containers have drifted from their definition, etc.

    I’m a developer that has sometimes done support for the apps I develop. That means that I laugh at your “Our images do not drift because we’re agile and build-driven.” Of course they do, because troubleshooting is real. The real question is, can you get them back into alignment when the ticket closes? The DevOps toolchain is pretty darned good at that if you let it. Changing a running image and telling no one is a terrible idea that still happens nearly every day across our industry. But technology has brought us drift monitoring. We can be notified of changes as they happen. For those in highly sensitive spaces like FinTech, changes can be blocked in production, but for most of us, we want to know when it is happening and who made the change. And we can get that today.

    Technology has also brought us some wonderful scanning tools from SBOM to SCA to Registry. These tools can give us a list of things for security to worry about in our images. In order to reliably generate these lists, we still have to know what images we are keeping and where—but choose a reliable registry or two, fit them into your DevOps processes and scan on commit. Simple and thorough—as long as everyone uses them.

    Thanks to policy and regulation,  container management tools can offer you a detailed list of not just what instances they’re hosting, but metadata like what image they came from. That helps manage inventory, and by now we are all building hierarchies of images from base to application specific.

    So, we can tell what is running, what images are available to run, how far running images have drifted, what known vulnerabilities exist in both our images and our instances and how compliant we are WRT containers. Dunno about you, but it seems technology has our back yet again.

    You are cranking it out, keeping the lights on, and dreaming of more you could be doing. Use the tools we already have to make it easier and the resulting systems more secure and reliable. You won’t regret it. And once again for those of you whose users never say it: Thank you.

     

  • Low-Hanging Fruit, 2023 Edition: Part Two

    Low-Hanging Fruit, 2023 Edition: Part Two

    Last time, we discussed setting up a comparative inventory system for your growing API footprint. The idea is that as security catches up to new technology deployments, enterprises will have to step up their game and implement those new technologies. API security is currently the biggest need because of exposure to the world, but not far behind it is container security, which we’ll discuss here.

    The point of container security is to make certain that your images are as secure as possible. Container security looks at source container definitions, added libraries and configuration options inside the container definition files ( or for those of you who prefer them, Docker files).

    A Tempting Target

    We are spinning up a bewildering number of containers these days, and having source images–particularly if they come from the outside–is a tempting target to attackers. Imagine if an attacker can hit the base container definition that all of your “golden images” come from and just insert a call to download a library. Soon, your entire application infrastructure could be a tool for that attacker to do as they wish. And if they’re cautious, they might get away with it for months (as many have).

    The Definition of Containers is Security

    So there is absolutely an imperative to ensure that the definition of containers is security–all of your containers. And there is an imperative to know what software is installed via container definition and what software is actually running on container instances. Much like our discussion about static versus dynamic API scanning, bad actors can modify a running container, so drift detection is half the problem, even while scanning registries and definition files has more appeal from the blast radius perspective.

    There are a lot of tools and vendors that range from simply scanning the files and generating an SBOM to complete container security by scanning the images, using the SBOM to perform software composition analysis, using data feeds to determine which software in the SCA is a threat, and how urgent or broad that threat is and monitoring deployed containers for drift. The more of these an organization implements, the more configuration and maintenance effort, but the payoff is security at a more fundamental level. The whole appeal of a container architecture is recoverability–if things go terribly wrong, we can redeploy easily. But if the source files hold the vulnerabilities, redeploying is temporary at best and likely would warn attackers that you’re onto them.

    Be Proactive

    So a more proactive approach is required. Obtain and install tools that will help you protect your container infrastructure, be they sold as container security, cloud workload protection, SCA or something else. The key is locking down this avenue of attack at the beginning of the software supply chain, not where you get the tools.

    And again, keep rocking it. As I said in the other post on low-hanging fruit, we need this because you all are serving the organization’s needs with the best solution for the job. Now that security technologists understand your new problem domain, let’s get tools into place to continue the protection of all that shiny new stuff.

  • We Are Living in an Ephemeral World

    We Are Living in an Ephemeral World

    We are lucky to live and work in the times that we do. Oh, we have our challenges, and I talk about them a fair amount here on these pages. But the things we can do in IT today have not been possible in the past, and the change isn’t over. Soon you will be able to relegate pretty much all of the busywork of IT to automated systems, Note that I did not say “AI/ML”–some of that automation will be, but we throw the term around too much right now, and not all automation will be based on AI/ML. In fact, quite a bit of the best automation is simply rule-based systems that we finally have things standardized enough to write up. And I intend to talk specifically about automation that is not AI/ML today.

    We have reached the point in DevOps where we can automate the entire build/release process using containers. The CI tool, running in a container, can spawn a container that performs the build. Then, when it is done, if it passed, it can spawn another container to run tests, do security scans, etc. Finally, the product can be promoted and released … in a container. Human involvement is only required for approvals and then only for organizations that want checkpoints on the way to production (which is definitely most but not all of us).

    If you take the totality of what is going on out there in DevOps, it is finally catching up to DevOps. The biggest issue will be making it efficient and doable for the DevOps team. To date, by focusing on DevOps, teams have been able to avoid the simple fact that complex deployments on infrastructure that spans environments and uses external resources is hard. By keeping the DevOps side simple (or not part of the DevOps process), developers can crank out code faster, facilitated by DevOps tools and Agile methodologies, and operations can continue to wrangle the beasts of networking, storage, etc. to get the app running in production. Once ops has completed the process, then it can be automated based on steps taken.

    But we now have Software-Defined Everything ™ combined with containers. That means that for many–though not anywhere near all–applications, a commit that updated a constant in a single source file can spawn the entire process in iterative containers all the way through release. That is very cool, and we should take a second to appreciate how far we’ve come in a short time.

    Then we need to talk about those worker containers. They need a ton of centralized logging and reporting. Spinning them up, letting them run and then automatically destroying them is fine—as long as the organization has access to the information it needs to review and analyze the results. In-application tooling will cover the released product and even the test environment, but not an ephemeral build process. By not keeping a ton of build tools running all of the time, the enterprise is, by definition, more secure—the blast radius is reduced if build tools are only available when they’re active, and logging of who/what kicked of a build is kept. But don’t forget the reporting. At build time, our tools know exactly which error failed a build; the container needs to submit a ticket before being destroyed or log heavily. I say, “Always create a ticket,” but I’ve worked in enough environments to know that your reality may not make that possible. As long as notifications occur, it doesn’t really matter how they occur.

    So crank it up; start super-automating. Tool up those build environments, then make them into disposable container instances. Others have been doing this for a while, so there is help available for setting it up, but it is just now taking off, so it is a good time to dive in. And keep rocking it. How the apps are built and deployed is only important in the sense that you are driving the company forward. Keep doing it.

  • The Right Tool for the Job: Container Edition

    The Right Tool for the Job: Container Edition

    I have written about “the right tool for the job” repeatedly. Because (again) we are absolutists in IT. My father was an antiques restorer that dabbled in flipping houses and was rather forceful about the “right tool for the job.” When I left the service and joined IT, it was something of a shock to me that the “right tool for the job” was considered situational.

    At the time, there were a large number of Microsoft zealots that loved Visual Basic, and a larger number of non-zealots that preferred C or Java. That was how we got to my first “right tool” article. VB was very strong with regard to UI and record crunching, while to-the-metal was C’s strength and Java fell in between the two—not being perfect at either. So my article stated that. Front-ending databases? Use VB. Writing drivers and low-level processes? Use C/C++. Need a bit of both and easy web page generation? Go with Java.

    It is many years later and time for an article that seems just as obvious to me, but in a different IT space. We have all heard of the three architectures: Data center, cloud and mixed/multi-cloud. We have also heard of how, in this rapidly changing world of DevOps, Agile and containers, different organizations are using different deployment methodologies. That’s all good so far. Just as the variety of programming languages available today is a bonus in many ways, so are multiple deployment and operations options.

    Where it gets sticky is when people include the “We’re an X shop” in conversations. Or try to do everything under the sun with one of these methodologies. For many of us, container infrastructure is perfect. Use an orchestrator like Kubernetes, build systems and security practices, then not have to care much if the Kubernetes instance it runs on is on-premises, hosted or cloud. Of course you have to care some. Networks have to connect, etc. But most of the work is done.

    Then there are the people that have use cases that don’t fit this mold and have not acknowledged that fact yet. This blog is for you. We’ve all heard of companies that have containers whose life expectancy is measured in seconds. Beyond that, I was told about a company that is using containers as message queues. Honestly. Creating a container with a startup command and putting it on a queue. When it is pulled off the queue, it executes that command and then goes away. We’ll call this crowd the “Over Users”.

    Finally, we have the people that cannot or will not be moving their systems anywhere. There are a variety of reasons for this, but these are companies that know their applications will continue to run in the data center for the foreseeable future. We’ll call this group the “No Needs”.

    For Over Users, that is literally what serverless is for. Create a queue with a (much smaller) call to an API in a serverless environment and be done. Fewer configuration issues, less maintenance, less everything but code. Add a trigger, remove entire OS/network/configuration generation and maintenance. The most likely resistance to this advice is “But we have an investment…” Yes. And for most orgs it is an investment in unnecessary technical debt. Divest. Keep the good parts—a container architecture meant to shuffle through many containers that exist for a short time is well-architected.

    For No Needs, before you port everything to containers—which I am generally in total support of—you should consider if you need to; think about if it offers any benefits and what the ROI of such a move is. Honestly. For DevOps-heavy shops or orgs that require highly portable solutions, the ROI of containers is quick and obvious. For orgs whose applications are not changing a ton and are highly unlikely to move anywhere, the ROI is a whole lot murkier. “But it gives us options!” is the most likely negative response to “We don’t need that right now.” But that’s the problem—you have those options now. What it gives you is a shifting of cost from some possible future where it might be needed to today’s already constrained budget. If there is a verifiable need—normally in portability, but any verifiable need—then make the move. Until then, spend that time and money making those apps rock.

    You’re doing it. The lights are on and the applications are useful. Use the architecture that makes sense for what you are trying to achieve. Right tool for the job, as my Dad often said (he said it a bit more forcefully when I thought a chisel was a screwdriver, but that’s a different story). Keep rocking it, and stay focused on need.

  • DevSecOps: Realities of Policy Management

    DevSecOps: Realities of Policy Management

    Policy management is essential to scale cloud environments and is key to secure DevOps practices. It enables organizations to manage policies put in place that secure the cloud environment, ensure Kubernetes configurations are secure and enable the continuous monitoring of a company’s overall security posture. 

     As businesses migrate workloads across multi-cloud architectures to achieve the agility and scalability needed to keep up with the pace of digital transformation, the growing demands placed upon developers often leave a gap that exposes potential threats and risks in the configuration settings, making security an even greater focus in DevOps. In fact, IDC’s 2020 survey found that 67% of breaches in the cloud are caused by misconfigured applications or infrastructure, including some of the industry’s largest breaches like Marriott’s second breach.

     To add to this, the first State of Policy Management report by Nirmata and the creators of the CNCF project Kyverno revealed that nearly 50% of users in cloud-native environments have now adopted some type of policy management solution. This tipping point of mainstream adoption across production cloud-native environments is making it critically important for DevOps teams to look at their practices and simplify and operationalize policy management across their Kubernetes stack by eliminating vulnerabilities through built-in, curated policies, without the barrier of learning complex policy languages. But this widespread adoption also acknowledges that organizations are finally realizing the need to put attention, investment and innovation into addressing security and compliance gaps as they adopt Kubernetes through proper DevSecOps practices and tools so applications being built can empower businesses.

    To confidently build cloud applications in Kubernetes, DevSecOps teams need to accept these DevSecOps realities and apply policy management effectively. 

     Customization Creates Security Risks

    Kubernetes can be highly customized, but DevSecOps teams need visibility into what’s happening in each cluster as organizations scale to ensure application reliability and security. Exploits on containers—including malware installation, cryptomining, host access and privilege escalation—offer opportunities for more security vulnerabilities. They can exist in images, production-accessible container registries, failed builds and third-party admission controllers in Kubernetes clusters.

    To address these risks in applications running on Kubernetes, it’s important to protect your environment with three A’s: Authentication, authorization and admission. This should be done at the cluster layer which enables secure access to authenticated entities that are authorized to perform certain actions. One way to accomplish this is through policy management. In fact, according to the State of Policy Management report, the top use case for policy management is for Kubernetes admission control (31%). When a request is authorized, having a policy in place ensures the request goes through another set of filters. For example, an authorized request may be rejected by an admission controller due to quotas or due to other higher-priority requests. In addition to validation, admission webhooks can also mutate incoming requests as a way of processing request objects for use before reaching the Kubernetes API server. 

    Configuration Issues

    Container images, namespaces, runtime privileges, persistent storage and control plane, together with network policies that are not compatible with best practices, are a source of misconfiguration and risk exposures. It’s this potential for greater risk exposures that have led configuration management to be a key driver of policy management adoption. In the Nirmata State of Policy Management report, it ranked third in security tools that are adopted today and fourth for the organization’s plans for future adoption.

    There are several ways to define security policies to protect cloud environments. Policies can be used for auditing purposes, to reject pod creation or to mutate the pod and limit what it can do. By default, pods can receive traffic from any source and send traffic to any destination. Network policies allow you to limit the ingress and egress access for your pods. The network policy typically translates to firewall rules.

    Lack of Adequate Authorization 

    Cloud authentication allows authorized users to securely access information stored in the cloud with authentication provided through cloud-based services. In The State of Policy Management report, key findings revealed that more than 24% of respondents today are using tools like policy management to authenticate users accessing applications. With data theft one of the fastest-growing and most expensive cybercrimes, the ability to process information and have strong authorization measures needs to be part of DevSecOps best practices.  

    In Kubernetes environments, as a user request is authenticated, it goes through an authorization workflow that decides if the request should be granted. It evaluates the request attributes against all policies and allows or denies the request. The main authorization mechanism is role-based access control (RBAC). Each authenticated request has an HTTP verb like GET, POST or DELETE, and authenticated entities have a role that allows or denies the request. Other authorization mechanisms include attribute-based access control (ABAC), node authorization and webhook mode.

    As the trend of moving security further to the left in the application life cycle accelerates, developers are being required to take active responsibility for it, which creates a higher desire for automation. The rapid releases can expose applications to many vulnerabilities, raising the risk of a breach.  With DevSecOps, organizations can transform the development pipeline by shifting security and compliance to the left, enabling developers to check the code before every commit. In doing so, security and compliance vulnerabilities can be identified and fixed in development, saving the organization from high costs and negative publicity from potential breaches. 

    There’s no doubt that Kubernetes is complex and challenging to adopt. On top of this, the development landscape is flooded with tools and more demands are being placed on engineers.  These shifts are changing the traditional role of a developer, leaving a gap for organizations to address to get the most out of DevOps. But by taking a secure, continuous, iterative approach that also includes policy management, companies can reduce the risk and exposure of their cloud environments. The more mature an organization’s DevOps practices are, then generally, the stronger the security and compliance practices are—they grow in relation to each other. The most innovative companies accept policy management in DevSecOps as a necessity of development and adopt some level of policy management best practices. With the right implementation tools like policy management and security and compliance best practices, organizations can remain efficient in agile and DevOps while adhering to critical go-live deadlines—which can’t be missed in this fast-paced business environment. 

  • What We Don’t Know is Dangerous

    What We Don’t Know is Dangerous

    Pop quiz: How many database management systems (be they RDBMS or NoSQL or even flat file) do you have running in your overall organization? Not actual databases, but management systems?

    How many containers do you have that are exposed to the internet, directly or indirectly? Not container management systems, because you’re only running a couple of those and they’re all relatively new, but actual containers?

    The questions could go on and on. Not too long ago, because there was an identifiable cost associated with it, cloud inventory management became a popular thing – finding and removing cloud instances, services and storage that were no longer necessary became a part of normal operations for organizations that had even a mid-sized cloud presence.

    But now, we have sprawl all over the place. So let’s extend inventory management to all software, and get rid of what isn’t needed on a regular basis … because it does indeed build up quickly.

    Yes, there are a few companies out there trying to do just this, and I encourage you to check them out. I have not, because our inventory at Ingrained Tech is manageable without that level of overhead. Our development and ops time is limited, so we keep a tight rein on what is out there and the maintenance it requires.

    But for larger organizations, the more you have out there, the larger attack surface and potential data sieves you have in place. So make sure if it isn’t needed, it’s gone. In the age of containers, this actually requires a fair amount of investigation; first, a list of all containers part of an ongoing project (and in even a mid-sized company, “They’re all together for each app,” won’t create this list because random containers are out there, too). And then a list of all containers not associated with a known project that can be gone through and usage determined.

    It’s not glamorous. It’s a bit of a slog. It’s in the organization’s best interests, though, and the slog should motivate your teams to put a policy in place to manage container life cycles. Like notes in Docker files that say when the container is no longer needed, or what it is needed for, so future you can easily get rid of it without stress.

    If you are in a containerized environment, this problem is growing almost by the day. Seriously. On our last project, we had 12 active containers before we pared it down to the five we needed long-term. The others were R&D along the way or tools we were using before focusing on a different method of achieving the same goals. Since we’re a small team, we just cleaned up when the project was coming into focus, but a larger org needs to be more focused on cleaning things up as they go.

    Meanwhile, those assets are letting customers get to your org, and allowing employees to manage the systems. Keep rocking it, and just remember to pick up, particularly after cutting-edge new projects, but also occasionally as just a normal cleanup step.

  • A Security Vulnerability Management Guide

    A Security Vulnerability Management Guide

    Living in a container-native world is not easy. Containers have a reputation for being a point of entry for security vulnerabilities for many organizations. In 2015, according to a research paper, over 40% of Docker images distributed through Docker Hub had high-risk vulnerabilities; at that time there were more than 95,000 container images hosted on Docker Hub. Today, there are over 3.5 million container images on Docker, and container security is of even greater concern. In a more recent 2020 study by a team of researchers at the Norwegian University of Science and Technology found container image vulnerabilities in certified and popular packages.

    This is just one example of one kind of security vulnerability. This article will share an introduction to security vulnerabilities and the role of vulnerability management for containers and other artifacts in a continuous integration and continuous delivery (CI/CD) pipeline.

    What is a Security Vulnerability?

    A vulnerability is a weakness or flaw present in software. Security vulnerabilities can be present in application dependencies or operating system (OS) packages. Common vulnerabilities include missing data encryption, buffer overflows, missing authentication for critical functions and insecure interactions between software components.

    There are different risks associated with different types of vulnerabilities. With critical or high-risk vulnerabilities, an attacker who exploits your software has the potential to seriously impact your organization. Risks associated with data breaches impact not only an organization, but also its end users and customers.

    Vulnerability Management Techniques

    Vulnerability assessment practices and tools exist to make detecting vulnerabilities simple, accurate and fast. Some of these practices include:

    • Penetration testing – Penetration testing, or pen testing, allows you to identify security vulnerabilities by attempting to break into your own systems to identify weaknesses.
    • Configuration management – Configuration management involves managing infrastructure configurations and identifying missing patches that leave your software service vulnerable to errors and risks. There are tools that provide infrastructure scanning as-a-service to help detect outdated or misconfigured instances.
    • Container and application Scanning – Allows you to detect vulnerabilities in deployable artifacts and running applications. Some available tools for container scanning include Twistlock, Clair and Trivy.

    These practices help build solid, repeatable vulnerability management techniques across your security and delivery teams. One way to scale these security practices is through security automation. Security automation is the use of technology that performs tasks with reduced manual assistance. It ultimately enables users to apply security decisions automatically and secure processes to deliver more robust applications and infrastructure.

    Security Practices in your CI/CD process

    Security automation is a core tenant of DevSecOps. DevSecOps is short for development security and operations, and it describes how organizations deliver and make security decisions and actions within the development life cycle of their valued deliverables.

    DevSecOps is a way of continuously integrating security in the software development life cycle. It’s a way of working and thinking so that security is at the forefront of how security teams deliver business value.

    One way to enable DevSecOps is through your CI/CD pipeline. Today’s enterprises can use CI/CD to accelerate better software delivery, but with that speed it becomes even more important to enable robust security. Vulnerability scanning improves software security while giving individuals across engineering and product teams accountability for each of the processes these teams own.

    Don’t let Security Vulnerabilities Ruin your DevSecOps

    This is a simple, basic introduction to security vulnerabilities and the risks they pose for your organization. There are practices and tools for detecting and reducing security vulnerabilities, and finding ways to incorporate those processes into a CI/CD pipeline is a great way to accelerate your DevSecOps.

  • You Have a Box: The Impact of Containers on DevOps

    You Have a Box: The Impact of Containers on DevOps

    To continue the discussion from my last blog post, you have a box. Increasingly, you only have to ask, “What do we want to put in it?”

    It is interesting to see the growth and change in IT over time. The advent of containers is the focus of this particular blog, but there are many other topics that would be fun to cover in the same manner.

    The fact is that containers have become our blank puzzle pieces. We take it, make it what we need and drop it in. They relieve us (for the most part) of the need to worry about deployment issues and allow us to focus on getting the part of the app they represent right.

    But those deployment issues didn’t go away, they’re simply obfuscated. Networking, security, storage and even capacity still have to be concerns of IT, just not concerns of a given app or its developers. That creates a separated world of issues, sometimes a split world of issues—such as networking inside/outside the container environment—but these are largely things we’ve had to deal with since the advent of virtualization, just in a larger scope.

    The true promise of multi-cloud comes with containers, also. Each cloud vendor wants to lock users into their container architecture, of course, but nothing stops a shop from running containers and container management on cloud instances of their own, maintaining the highest level of portability for the cost of some extra management headaches. In the end, where it is running is even less important in the container world, and that allows what it does to gain more importance.

    Management of containers has a bit more overhead; after all, hardware or cloud management needs are the same, and the configuration/management of containers is layered over those needs as an additive. But that’s a worthwhile cost to bear if the result is that tomorrow the container could be thrown to a cloud instance, and the next day for whatever reason—capex versus opex, data accessibility, whatever—could be brought to a local server. Maximum flexibility makes the cost of maintaining another layer of management.

    And much of that layer of management can (and usually is, in my experience) be folded into DevOps practices, precisely because a container is 100 percent software. That means the overhead is not nearly as large as it seems. And what isn’t well-covered by DevOps is simply an extension of virtualization.

    So with containers, you have a box. The management of the box is handled by DevOps. The only question that really matters is, “What are you going to put in the box?” And that’s pretty cool: Less to worry about during development means more time to make whatever goes in the box rock.

    And the innovation around those boxes is just getting geared up, I think. We already see things such as shops/projects with a container life expectancy of less than a minute that are inconceivable in other environments. Not that they’re all good ideas, but the more people doing things in a different manner, the more opportunities for really great discoveries to come along.

    And you will be there. Filling boxes with cool new apps. Pretty sweet.

    — Don Macvittie

  • 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

  • Containers as Disposable Servers?

    Containers as Disposable Servers?

    There is a belief in the space where containers meet DevOps that a service hosted in a container crashing is no big deal, and you can just spin up a new one. It’s not a pervasive belief, but it is common enough that we’ve all heard/read it somewhere.

    I think this view of the world is, at best, incomplete. There are easily verifiable cases where it just isn’t reality. A good example is the Cloudbleed bug, where ignoring errors and spinning up a new instance to meet load demands was one of many things that combined to make a sensational (if low-risk) failure.

    Another good example is shopping carts and payment systems. All the small-business owners I know would balk at a shopping cart of payment processing system that could crash mid-transaction, and the provider shrug and say, “We spun up another instance; have the customer try again.”

    Are there scenarios where crashing containers simply being replaced might be acceptable? I would argue no. They’re software errors. The world has not changed; errors are still bad. I can invent “but if you …” scenarios as well as the next person, but the fact is, if your software is crashing—be it container, VM, hardware, firmware or whatever—you did something wrong and you can’t know the extent of the issues the crashing creates without digging into the problem. At which point, you may as well fix it.

    I’ve written my share of bugs, like any developer. And I’ve fixed my share of bugs, like any developer. Ignoring them is a recipe for disaster, when a seemingly benign bug is suddenly exposed to have major issues.

    Schedule time to fix issues. Rushing forward with new features and products is cool, but keeping the customer base happy and safe is far cooler when revenue time comes. If containers and DevOps are saving you the time they’re supposed to be, you have a little extra time to get in there and fix issues, so use it productively.

    — Don Macvittie