devopsy.kinsta.cloud

Tag: cloud cost management

  • Review, Review, Review

    Review, Review, Review

    Ossification is an issue in IT, and always has been. It is borne largely out of staff and management knowing what to expect from existing software/infrastructure, and the deep product knowledge that allows teams to make existing systems do what is needed. But this becomes a series of rocks that the ship of progress smacks into.

    Contrary to popular belief, DevOps and other new methodologies are not immune to this problem. Quite the contrary, we’ve spoken with people that say “We’re a Jenkins shop,” which sounds exactly like “We’re an Oracle shop” of a decade ago. The wave just ushered in new tools, it didn’t change tendencies. OK, it did more than usher in new tools, but it didn’t change tendencies.

    So, it’s time for a friendly reminder: Review what you are doing, review cloud usage, review tools in the toolchain, review methodologies, review security posture (which has suffered in this environment for far too many shops) and review customer satisfaction.

    Many organizations used the push of Agile and DevOps to update stagnant parts of the infrastructure and development toolsets. Don’t let them become stagnant again. Just as you don’t want change for the sake of change, you don’t want to stay with one tool or methodology just because it is comfortable.

    This isn’t some easy task that I ⁠— or anyone else, no matter how much they try to tell you differently ⁠— can dictate to an organization. There isn’t a handy list, because no two organizations are exactly the same. Not in toolsets, not in culture and not in appetite for risk. The only thing we can offer is guidance to look closely at where you are, what’s available in a given area ⁠— Application Release Orchestration, for example ⁠— and evaluate the available tools just like you were making a fresh choice and did not have a tool in place. Then do the same for processes. Is this the best process for what we’re trying to achieve? Are there tweaks we can make to it? Should we completely change the process to take in changes in environment that have happened since we adopted this process?

    Finally, if you don’t have someone responsible for monitoring cloud costs, appoint someone. Get them the tools, help them understand where the money is going and what cloud-based server usage is. Could these servers be spun down outside of business hours? Could we follow the sun better by staggering cloud data centers in which cloud servers are active, rather than hosting them always in one location or leaving them on 24/7 in multiple locations? Is one team using a cloud feature no one else is? If so, how does it apply, and are the other teams not using it because they don’t need it, or is there some other solution they’ve adopted?

    Basically, question everything. We’re launching a new project that will be a simple dynamic app. Make a few selections from a limited list, get a summary of what you should do and why. It is all really quite simple. Should we host in a web page or make it a standalone mobile app? If mobile app, what tools for development and what targets? Integration of Git — should it be local or on one of the big providers? Do we want any team member to trigger builds on commit or do we want someone managing branch merging before-hand?

    These are all things we already do on other projects, but we’re digging in and seeing what could be better. What could we improve, and what would the rewards for that improvement be? It takes a bit of time and some discussion. We’re confident we’ll burn through it in the next day or so and come up with a plan for development and architecture that best suits the app, but is informed by where we’re at now. It’s been a fun exercise, to be honest. If nothing else, it gave us a strong reminder that any given cloud provider’s “simple” pricing is not that simple, and we need to pay more attention to app characteristics versus fees.

    You’ve rocked it this far, even kept the lights on during the great shift to working from home. Don’t stop improving the environment though, find innovative ways to make it better and keep clipping along.

  • Multi-Cloud Cost Optimization For The Enterprise

    Multi-Cloud Cost Optimization For The Enterprise

    Multi-cloud is an increasingly popular approach for deploying enterprise computing assets. But, in the same vein, managing cloud costs has become a huge challenge. Whilst public cloud continues to grow in popularity, there are many factors that can increase a cloud bill that needs to be taken into consideration. A smart cloud cost management strategy certainly helps to avoid any unwanted billing surprises. Enterprises progressing through their cloud adoption need one in place to control their spend.

    The benefits of cloud infrastructure—scalability, control, security, etc.—are easily seen, but there are challenges, too. Perhaps the biggest challenge of cloud cost management is the difficulty that organizations have in tracking and forecasting usage— these uncertain budget costs can be a massive cloud management pain point. The ability to scale up and down on demand has allowed resource procurement to transition from sole ownership of the finance or procurement team to stakeholders across IT, DevOps and others. Procurement is now in the hands of a group of cost-conscious stakeholders who are responsible for understanding, managing and optimizing costs.

    How much will the public cloud cost? You should begin your cloud cost management strategy by looking at the public cloud providers’ billing models—just like any other IT service, the public cloud can introduce unexpected charges. How much storage, CPU and memory do your applications require currently? Which cloud instances would meet those requirements?

    Then, it’s a question of estimating how much those applications would cost in the cloud and comparing these figures to how much it currently costs you to run them on-premise. If you plan to use multiple public cloud providers, integration and other factors can lead to unexpected fees—try and plan application deployments to see where you might be liable for extra costs. 

    Initially, it seems that most vendors offer similar packages and prices—when you examine them in detail however, perhaps one vendor has a much lower price for certain types of workloads. Understand your business requirements before committing to a cloud vendor, and avoid vendor lock-in. Moving workloads from one cloud vendor to another can sometimes be difficult. If you don’t do your due diligence here, it can be subsequently too difficult to migrate applications or workloads after they are in production.

    Confronting Cloud Costs

    You must first identify waste by uncovering inefficient use of cloud resources. Cloud cost management is not a one-and-done process, but you can make a start saving money on your cloud infrastructure costs if you address key areas that account for the majority of wasted cloud spend and budget overruns.

    Visibility

    Ensure teams have the direct ability to see what they are spending. It’s easy to get carried away spinning up services, unless you know exactly what you are already spending. Identify what you have, and who owns it. Tag resources with user ownership, cost center information, product name and others to give you a better handle on where the spend originates. This information can be used to track usage through detailed billing reports.

    Budgeting

    Once you have a handle on what your spend is, set budgets per account. Doing this after establishing a baseline ensures that you are setting practical and realistic budgets that are based on the actual usage. Look to whitelist instance types (RDS & EC2) to only allow instances of specific types, classes or sizes.

    Manage Storage Lifecycle

    Ensure that you are rotating logs and snapshots regularly and backup and remove any storage volumes that are no longer in use. Ensure that you are using only one logging configuration and have added additional ones only when absolutely necessary. Also, ensure that sandbox or trial accounts are only utilized for exploration purposes and for the duration committed.

    Use Containers

    Another technological solution that can help to reduce operating expenses is the use of containers. Often used by IT teams taking DevOps approaches, containers package applications together with all their dependencies, making them easier to deploy, manage and/or migrate from one environment to another. Containers can also be more cost-effective on one hand but can cause more complexity, and therefore increase costs, if built in the wrong way.

    Review Regions

    Prevent staff from provisioning unapproved virtual instances from the marketplace that include software license costs, or from using specific OS or DB engines from vendors with whom you do not have enterprise agreements in place or are too costly to run at scale. Review in which regions you have services running. The cost of services per region can vary as much as 60%. You need to ensure you are balancing the need with running services in a given region with the cost of doing so. You can use instance scheduling to start and stop instances on a planned schedule. Shutting down environments on nights and weekends can help save you 70% of runtime costs. Look to determine which environments need 24/7 availability, and schedule the rest.

    Use a Cloud Cost Management Vendor

    Many organizations decide that tackling these cost optimization chores on their own takes too much time and skill. Instead, they leverage services from reputable cloud cost management vendors. Cloud cost management is one of the major pain points organizations confront when migrating to the cloud—cloud costs are difficult to estimate without some kind of assistance, due to the complexity of cloud infrastructure.