devopsy.kinsta.cloud

Category: DataOps

  • The Database of the Future: Seven Key Principles

    The Database of the Future: Seven Key Principles

    The database of the future will be more than just a database. Instead, it will be a platform that focuses on the user experience and abstracts the technology. Looking at the evolution of application development, an enormous amount of effort has made it easier to build and deploy applications. Similarly, databases need to evolve for ease of use with a delightful developer experience and an exemplary user interface that surfaces features and functionalities that engineers will actually use.

    Here are seven principal features needed to chart the development of the future database.

    1. Serverless by Default

    Serverless is unquestionably the most significant paradigm shift in software engineering in the last five years and the one that’s been realized the least. There aren’t that many people at this point that are all in on serverless. It’s the shift away from buying a server to a service that does what you need and scales with your growth.

    Serverless by default is the only way to ensure the database of the future will be easy to operate while being consistently reliable. Serverless is evolving from running functions in the cloud to becoming the standard for fast-paced development teams that don’t want to worry about vCPUs or node pools but focus on outcomes.

    The companies that are doing it the best still deploy servers, but they are leveraging products that scale independently, regardless of how many servers they have. Their component vendors can increase the number of resources allotted to them, and they only pay for what they use, and the architecture of the solution scales in that way. They’re not buying a single server and pushing it as hard as they can. They’re telling one platform, ‘here’s my code,’ they’re telling another, ‘here’s my data,’ and then that scales up based on usage much, much farther than buying a single server.

    When people think serverless, they think JavaScript and Lambda, but there’s serverless PHP out there, too. It’s not just the JavaScript community. Other software paradigms are going for this. We will see more and more people pulling this out when they need to do some quick code and they want to ship to production as quickly as possible and scale as quickly as possible.

    2. Easy to Operate

    The most significant advancements in DevOps have been freeing developers from complex operations that overwhelm their day-to-day operations. Engineering teams today are organized around product and business goals, not maintenance and servicing. But databases have yet to catch up. Product teams still rely on experts to perform overly complicated database operations tasks.

    The database of the future must fit into everyone’s DevOps workflows. It must be usable for any developer and leveraged by every team within a technical organization. The database needs to be operable by everyone and no longer require database admins to manage backups and capacity planning or worry about disaster recovery.

    Developer-centric features like database branching, database developer environments, autoscaling and usage-based billing will be commonplace.

    3. Reliable

    Reliable simply means it’s harder to hit the scaling limits. Not only does it mean that the database is there, but that you get the right information when something is going wrong, and you can collaboratively help scale.

    Nothing scales infinitely. There are not enough computers in the world to scale something to infinity. You’ll always be able to query a database and pull too much information out of it too fast. No matter how many cars you get or how much horsepower you have, you can’t go a million miles an hour. A good database must let you know when you’re hitting those limitations and help you move past them, whether at a small scale, medium scale or large scale.

    4. Interoperable

    Future databases will be accessible to every imaginable client–from smart refrigerators to fleets of autonomous delivery vehicles. But this client-agnostic approach requires planning for many more transactions and connections than most current databases could ever manage simultaneously.

    In the future, databases can handle unlimited connections through smart connection pooling, query replication and intelligent query routing. Databases will also need to serve a wide set of connections and clients. Although we are already seeing many databases offering web APIs and new connection types, as these get tested at scale, we will begin to see them adopted and used to power the next generation of applications.

    5. Globally Distributed, Locally Available

    Today, most businesses and applications don’t need a global database, which often introduces unnecessary complexity and operating costs. However, there are many reasons the future database will need to be globally distributed, as they must be located where you need them the most.

    The key to this is knowing what your requirements are. Many people look at multi-region and think it’s faster reads, failover, scaling and breaking the speed of light. Ultimately, it’s all a series of tradeoffs. For example, when you read from a local replica, you trade off consistency because you have asynchronous replication. But this is really leveraging the global internet to deliver a better outcome where it’s necessary.

    Being compliance-ready with regionally stored data enables you to scale rapidly to a new region and provides a great user experience by quickly serving locally available data. High-transaction, low-latency applications such as mobile games already need this capability.

    But there’s one caveat: Global data distribution cannot break principle number two—being easy to operate. Tools will need to be elegant and have straightforward interfaces as their main goal is to make operations easier, not harder.

    6. Intelligent

    The future database is intended to be used by people and will be able to tell them how it needs to be used and how to make it better. All the tools you buy today can only give you the data you need to make some educated guesses. The future database will replace that with concrete recommendations, then self-healing actions.

    This starts with basic data collection and observability and moves to, “let’s record every query that someone makes and use some decision engines and some AI and recommend how they can shard automatically.” It will be able to say, “I’ve recorded your database use for the last 30 days; this is how you should shard for optimal performance. Click the button, and we’ll do it.”

    The future database will say, “You’re scaling too far for the single machine at a per-user level. You must break it down into two or break it down into four, and we figured out how to do it for you, so you don’t have to figure that out. We’ve sharded your data on your behalf.”

    7. Linearly Horizontally Scalable

    Future databases will also need to be designed for future scale. Only a handful of companies on the planet have hit a scale that tests the limits of current technologies, but as information grows, more companies will get there. The next databases will do that by automatically scaling both vertically and horizontally within seconds. Many existing databases require a maintenance window, replication and a failover before they can be scaled up or out. But downtime is unacceptable, and scale should not come at the cost of performance. And it doesn’t have to. The database of the future will scale intelligently and without a blip on the status page.

    In short, the consumer should be able to get what they need when they need it, with no risks. It should be easy to say, “I’ve doubled the number of servers, I’ve doubled the amount of throughput. I’ve quadrupled the number of servers and the amount of throughput.” This is what sharding provides. Good sharding happens automatically at a super high scale, and you’ll only pay for what you use as you go along. The future database will do all of this without users having to turn a knob.

    In conclusion

    It will take the entire database industry to agree on these principal features, adopt a user-focused approach and build future database platforms designed to make engineers more successful by delivering superior products and services to their customers. I envision a day where every company no longer worries about its infrastructure and can simply focus on its business. I want development teams to take back control over their development workflow. Using a database should be as easy as writing code.

  • Why MLOps Hurts: 3 Pain Points for DevOps Teams

    Why MLOps Hurts: 3 Pain Points for DevOps Teams

    Machine learning operations (MLOps) is a practice that aims to improve the collaboration and communication between data scientists and IT professionals in the development, deployment and maintenance of machine learning models.

    MLOps aims to streamline the process of building, testing and deploying machine learning models by automating and standardizing the various tasks involved. This includes automating the training and testing of models and the deployment and management of models in production.

    MLOps involves using tools and processes to automate the various steps involved in machine learning model development and deployment. This includes tools for version control, continuous integration and continuous deployment (CI/CD), and tools for monitoring and managing the performance of machine learning models in production.

    By adopting MLOps practices, organizations can improve the speed and efficiency of their machine learning model development and deployment and reduce the risk of errors and inconsistencies in the process.

    What Role do DevOps Engineers Play in MLOps?

    In MLOps, DevOps engineers play a crucial role in supporting the development and deployment of machine learning models. Their responsibilities may include:

    • Setting up and maintaining the infrastructure needed to support machine learning models, including hardware and software environments, data pipelines, and monitoring systems.
    • Automating the various tasks involved in machine learning model development and deployment, including training, testing, and deployment, using tools such as continuous integration and continuous deployment (CI/CD).
    • Monitoring the performance of machine learning models in production and troubleshooting any issues that may arise.
    • Collaborating with data scientists to understand the requirements and constraints of machine learning models and to help them implement and deploy their models effectively.
    • Managing the release process for machine learning models, including coordinating with different teams, conducting testing and validation, and rolling out updates and improvements.

    Challenges to Implementing MLOps

    MLOps is not without its challenges. Here’s what to consider when developing and deploying your machine learning pipelines. 

    Data Security

    Data security is a key challenge of MLOps for DevOps teams because machine learning models rely on large amounts of data to function effectively. Ensuring the security and integrity of this data is critical to the success of the model and the overall MLOps process.

    There are several risks to data security that DevOps teams need to consider in MLOps:

    • Data breaches: Machine learning models often work with sensitive data, such as personal information or financial data. If this data is not secured properly, it could be accessed by unauthorized parties, leading to data breaches and potential legal and financial consequences.
    • Data tampering: Machine learning models rely on the accuracy and integrity of the data they are trained on. If the data is tampered with or manipulated, it could affect the model’s performance and lead to incorrect or unreliable predictions.
    • Data privacy: Machine learning models may work with data that is subject to privacy regulations, such as the General Data Protection Regulation (GDPR) in the European Union. Ensuring compliance with these regulations is critical to avoid fines and other consequences.

    Model Deployment

    Model deployment is a key challenge of MLOps for DevOps teams because it involves integrating the machine learning model into an existing application or system and setting up the infrastructure to support it. This can be complex, especially if the model is part of a larger application or system, and requires careful planning and coordination.

    There are several challenges that DevOps teams may face when deploying machine learning models:

    • Integration: Machine learning models need to be integrated into an existing application or system in a way that is seamless and does not disrupt the overall functionality. This can be a complex task that requires careful planning and testing.
    • Testing: It is important to thoroughly test the machine learning model before it is deployed to production to ensure that it functions correctly and meets the required performance standards. This may involve testing the model on a variety of data and in different environments to ensure that it is robust and reliable.
    • Performance: Machine learning models may require specialized hardware and software environments to support their performance. Setting up and maintaining these environments can be a challenge for DevOps teams.
    • Scalability: Machine learning models may need to scale up or down depending on the volume of data and the demands placed on them. Ensuring that the model is able to handle different workloads and scale appropriately is a key challenge for DevOps teams.

    Model Performance and Maintenance

    Model performance and maintenance is a key challenge of MLOps for DevOps teams because machine learning models require ongoing monitoring and maintenance to ensure that they continue to perform well in production. This can be a complex and time-consuming task that requires close collaboration between data scientists and IT professionals.

    There are several challenges that DevOps teams may face when it comes to model performance and maintenance:

    • Model drift: Machine learning models can suffer from model drift over time, where the model’s performance begins to degrade due to changes in the data or the business requirements. This can be difficult to detect and can significantly impact the model’s accuracy.
    • Data changes: Machine learning models rely on the accuracy and integrity of the data they are trained on. If the data changes over time, the model may need to be retrained or updated to ensure that it continues to perform well.
    • Hyperparameter tuning: Machine learning models often have several hyperparameters that need to be set to optimize their performance. Identifying the optimal values for these hyperparameters can be challenging and the model may need to be retuned over time to maintain its performance.
    • Model versioning: Machine learning models may need to be updated or replaced over time to improve their performance or to address issues. Managing different versions of the model and coordinating the rollout of updates can be a challenge for DevOps teams.

    5 MLOps Best Practices to Help DevOps Teams

    There are several best practices that DevOps teams can adopt to help overcome the challenges of MLOps:

    1. Automate as much as possible: Automating tasks such as model training, testing and deployment can help streamline the MLOps process and reduce the risk of errors and inconsistencies.
    2. Use version control: Version control systems such as Git can help track changes to the machine learning model and its supporting infrastructure, making it easier to roll back changes or deploy updates.
    3. Use CI/CD: CI/CD pipelines can help automate the process of building, testing, and deploying machine learning models, improving the speed and efficiency of the MLOps process.
    4. Monitor and log model performance: Setting up monitoring and logging systems can help DevOps teams track the performance of machine learning models in production and identify any issues that may arise.
    5. Collaborate and communicate effectively: MLOps requires close collaboration between data scientists and IT professionals. Establishing clear communication channels and effective collaboration processes can help ensure that all parties are working towards a common goal.

    Conclusion

    In conclusion, MLOps can be a challenging process for DevOps teams due to the complexity and specialized nature of machine learning models. There are several pain points that DevOps teams may face when implementing MLOps, including the complexity of setting up and maintaining the necessary infrastructure, the difficulty of collaborating and communicating effectively with data scientists and the challenges of ensuring the security and integrity of data used to train and test machine learning models. 

    By adopting best practices such as automation, version control, CI/CD pipelines and effective collaboration and communication, DevOps teams can help overcome these challenges and improve the speed and efficiency of machine learning model development and deployment.

  • Why GraphQL Will Reign King

    Why GraphQL Will Reign King

    After years of development, GraphQL is set to reign as the go-to API for data fetching. But what is GraphQL? Simply put, it’s a query language that allows you to fetch data from any server, and it’s a noteworthy alternative to the likes of other web service development styles like representational state transfer (REST) and simple object access protocol (SOAP). There are a few reasons why GraphQL will dominate the DevOps world, including its overall efficiency, ability to work with any server and overall ease of use.

    Understanding GraphQL

    GraphQL is a query language for APIs and a runtime for fulfilling queries with existing data. GraphQL provides a complete and digestible description of the data in an API, gives clients the power to ask for exactly what they need, makes it easier to evolve APIs over time and enables powerful developer tools.

    Top Benefits of GraphQL

    GraphQL addresses many pain points that often slow down developers, who prioritize adaptability and working quickly and efficiently when building applications.

    For one, it is much more flexible than other data query languages, allowing users to specify exactly what data they want and in which format. Other data query languages require users to retrieve all data in a specific format, regardless of whether they actually need the data. That excess, unnecessary intake can cause delays and confusion.

    GraphQL’s ease of use is also invaluable, thanks to its simple and intuitive syntax. The language is strongly typed, which means developers can catch errors early on in the development process before code goes into production. This can save much-needed time and money in the long run.

    Another benefit is that it can be used to fetch data from multiple sources because it uses a schema that defines the different types of data available. This means if a developer has a field in a schema that could potentially return data from multiple sources, they can specify which source to fetch the data from. Developers don’t get this benefit from other data query languages, which often allow data fetching from only a single source.

    Advantages for DevOps Teams Over Other Data Query Languages

    As the world of software development continues maturing, so do the tools and technologies DevOps teams use to build and operate their applications.

    REST and SOAP are popular web service technologies, but they come with some major drawbacks. Notably, both REST and SOAP rely heavily on URL structures and verbose XML payloads, which makes it difficult to evolve the API without breaking existing clients. And because each endpoint is a unique URL, providing a consistent experience across different parts of the API can be challenging. REST and SOAP are also quite chatty and can make it hard to optimize performance.

    In contrast to REST, GraphQL provides a single endpoint for all data requests and is much faster than making many HTTP requests. GraphQL’s declarative query language specifies precisely the data needed – no more, no less – increasing bandwidth and improving performance. Applications can run faster and use fewer resources, which is especially important for mobile apps that need to be lightweight and fast.

    Understanding the data is crucial for DevOps teams, and GraphQL allows developers to visualize data in a graph. Teams can see the relationships between different points more easily, leading to better-informed decisions about the best ways to manipulate the data.

    The increased efficiency when conducting API calls is also a plus with GraphQL, which helps teams retrieve all information they need with a single API call. Traditional REST APIs often require multiple API calls, mainly because each resource in a REST API is represented by its own unique URL, along with its own set of permissions and data that needs to be retrieved. GraphQL can eliminate this bottleneck.

    Overall, dealing with complexity is significantly reduced when developers use GraphQL. When using traditional REST APIs, writing a lot of code to handle different edge cases and error conditions is the norm. But GraphQL streamlines this – much of the complexity can be handled by the server itself, making way for simpler and more maintainable codebases. DevOps teams are also able to decouple their front-end and back-end development efforts by using a schema-based approach. GraphQL enables frontend and backend components to be developed separately without worrying about breaking changes, which means faster development cycles and fewer errors.

    The amount of data that organizations need to understand, organize and query will only increase in the coming years. DevOps teams can get ahead of the ongoing data and information onslaught by taking advantage of GraphQL and its unmatched ability to provide an efficient, powerful and flexible API for data fetching and manipulation.

  • 5 GraphQL Trends to Watch in 2023

    5 GraphQL Trends to Watch in 2023

    The GraphQL query language had a big year in 2022. We witnessed its increase in production use cases, solving overfetching and underfetching concerns that plagued traditional API integrations. GraphQL can significantly improve usability, aggregate multiple services and optimize how data is ported from system to system.

    Yet, GraphQL is also prone to new security concerns. And as attacks on APIs continue to increase and grow in sophistication, an increased security focus will undoubtedly be required to avoid vulnerabilities. The coming year will likely also see architects grappling with their GraphQL maturity as they consider how best to scale its use across an organization and its various stakeholders.

    Below, we’ll consider where the tides are flowing for GraphQL in 2023. These forecasts are informed by my coverage in 2022 and reports from within the web development community.

    1. Increased Production Use

    A full 62.6% of developers reported relying on APIs more in 2022 than they did in 2021, according to RapidAPI’s State of APIs report. As the number of APIs in use expands, we will undoubtedly see more GraphQL examples. GraphQL is popular due to its usability and flexibility which outweighs traditional integration points. Studies showed it is primarily used for exposing internal data, although partner and public use cases are not uncommon.

    Representational state transfer (REST) remains a dominant style for modern APIs. According to Postman’s 2022 State of the API report, 89% of developers use REST. GraphQL is in fourth place at 38%, superseded by webhooks (35%) and SOAP (34%). Although usage remains small in comparison, it’s steadily gaining traction and will continue to expand.

    2. Unifying Disparate APIs

    GraphQL helps expose fields in an easily consumable manner. But it’s also good for aggregating disparate microservices into a unified schema. As such, it is often used as a meta layer that combines multiple REST services, databases and even GraphQL schemas. For the time being, it appears that REST has staying power. And it’s unnecessary to migrate all REST services to GraphQL. Looking to the future, it is more likely to be adopted as a layer on top of existing REST APIs.

    Combining multiple backend services under the hood and exposing them in a unified schema creates a more usable, localized interface that frontend developers can work from. In the future, GraphQL might become a meta layer for more organizations, increasing the discovery of internal services and helping teams reuse internal microservices.

    3. Supergraphs and Subgraphs

    As mentioned above, GraphQL is used not only to combine legacy REST services but also to combine multiple GraphQL schemas. Some call this a graph of graphs—or a supergraph. A supergraph that combines multiple GraphQL schemas would offer unparalleled developer experience in that engineers can access many services from the same endpoint.

    However, there’s a downside to centralizing with a unified graph. Different internal teams or partners might only need access to a particular set of functions. Giving the entire schema to every person who walks through the door would be TMI, not to mention a potential security risk that breaks the rule of least privilege. So, the idea of a subgraph has gained traction. A subgraph is an Apollo concept, but the theory could certainly be applied in other implementations. In the future, we’ll likely witness more use cases that use subgraphs to help federate a supergraph across an organization, helping segment a graph to specific stakeholders’ needs.

    4. Turning on GraphQL Security Controls

    As of 2022, less than half (43.2%) of GraphQL implementations have disabled query introspection. Disabling field suggestions and introspection are means to reduce the risks of public GraphQL exposures. As GraphQL security best practices become more apparent, these numbers will likely become more commonplace. Other security controls, such as implementing query timeouts, query rate limiting and query cost analysis, can also help curb potential malicious behaviors.

    As we’ve covered before, security by obscurity is not enough to protect GraphQL. Yet, many native GraphQL security and performance directives go unused. Besides turning on these advanced features, new tooling is coming to market that could harden GraphQL. Security vendors continue to add support for GraphQL, making its protection more accessible for non-security engineers.

    5. Managing GraphQL at Scale

    GraphQL has arisen in some large production use cases in recent years, helping developer usability at GitHub, boosting productivity at Netflix and aiding Shopify’s API strategy. These case studies proved its usefulness in large enterprises. But how do we effectively scale GraphQL across a massive organization?

    The concepts of supergraphs and subgraphs are ways to help scale it across a company. But retaining high performance will also be vital to maintaining an effective, scalable footprint. As such, we will likely continue to see companies optimize how GraphQL is used as it matures. This includes optimizing queries and query depth and applying filtering and rate limiting to fit application demands. Taking measurements of GraphQL response times will be necessary to establish benchmarks to improve over time.

    We’re Just Querying the Surface

    Above, we’ve only scratched—or queried—the surface of the exciting developments on the horizon for GraphQL in the coming months. There is much more to be said regarding updates to the query language and improvements within the surrounding tooling landscape. Where do you think GraphQL will go in 2023? Let us know in the comments below!

  • How Embedded Analytics Can Transform Future Businesses

    How Embedded Analytics Can Transform Future Businesses

    It’s no secret that big tech companies like Google, Amazon and Netflix are not only leveraging data but also delivering embedded analytics and insights as a standard functionality of their software, services, applications and toolkits. The analytics appear to consumers as recommendations, usage habits and other helpful information. Such insights not only help consumers extract the most value out of the product they are using but also help providers understand how they can provide better services. Businesses that embed analytics to provide a differentiated user experience also have a direct impact on engagement and revenue.

    Have you considered how embedded analytics could differentiate your company’s own software and hardware products? Let’s understand how embedded analytics can help transform technology businesses:

    1. Analytics are expected and welcomed in your products

    By embedding analytics into existing enterprise software and applications, users can drill down into real-time and context-aware data (for example: How busy a location will be at various times of the day) and can benefit from faster data-driven decision-making without worrying about application compatibility. Commonly, software applications provide in-app analytics to delight and serve their customers, while hardware companies can provide helpful stats on a web portal or app.

    2. Embedded analytics is easier than ever today

    Cloud technology has completely disrupted tech-enabled industries. It’s easier than ever for software, apps and hardware to connect to a data repository to save logs that are a rich source of analytics. The invention of the S3 bucket and object store has made it fairly cheap to keep log data. Finally, the transition to platform-as-a-service (PaaS) and software-as-a-service (SaaS) has fundamentally added an “easy button” to tracking consumption patterns and resource utilization.

    3. Embedded analytics helps design better products and services

    Embedded analytics can give businesses more insight into application telemetry (how customers use the data, how they engage with the product) and provide insights into the challenges they face from a usability standpoint. Providers can use advanced analytics to quickly iterate, draw patterns and make predictions, troubleshoot customer challenges, discover new avenues to monetize, detect and mitigate security threats or create entirely new features and applications that put customers on a faster path to improved application experience and better decision-making.

    4. Embedded analytics increases operational efficiencies

    The tech industry is transitioning from traditional monolithic architectures where applications are self-contained to microservices architectures where different components are spun up as needed via API calls. By embedding analytics directly into developer tools, businesses can manage resources without sacrificing availability or performance. Companies can allocate and optimize resources dynamically and understand peaks and valleys in consumption. Businesses must be able to leverage historical and real-time data to build predictive models to proactively identify and mitigate issues with individual components of the application before the customer experiences a problem.

    Embedding Analytics in Your Application

    Before you start embedding analytics in your application, it’s important to choose the right database foundation, as this will support current needs and future goals. Below are the top capabilities that should be standard features in analytics databases:

    1. Handles massive data volumes: The database must scale easily and efficiently with minimal cost using massive parallel processing. Today’s scale might be terabytes, tomorrow it might be petabytes and so on.

    2. Enables speedy data analytics: Speed is a key factor in a positive user experience. Users want instant insights because they don’t like waiting for results. The database should be capable of optimizing load and query performance so that analytics is both timely and relevant.

    3. Embeds machine learning: Machine learning algorithms are critical for predictive analytics. A platform that can embed ML and iteratively learn from new data can make a big difference and add a whole new level of intelligence.

    4. Features native integrations: The more time developers spend figuring out tools and integrations, the less time is spent innovating. The platform must ideally have out-of-the-box integrations with popular applications, data sources (on-premises, cloud, multi-cloud or hybrid), ETL, and visualization tools (e.g., Microstrategy, Looker, Power BI, Qlik, Tableau). It should be flexible enough to support user-defined functions for things that don’t have native integration.

    5. Encourages self-service: The database should make it easy for data scientists to leverage tools and programming languages they already know such as R, Java, C/C++, Python and SQL. Data scientists will also appreciate a platform that has built-in functions for a wide range of analytics (such as geospatial, time-series, event-series, real-time, machine learning, text analytics, pattern matching and regression) and delivers the tools to spot trends, uncover anomalies and anticipate the unexpected.

    6. Supports highly advanced analytics: Many platforms can analyze single tables or do a simple look-up but few have the power to analyze dozens of tables, hundreds of data types, dimensions and attributes from numerous sources over several years of history.

    7. Unified: The database should be able to streamline everything right from data ingestion to exploration to production until delivery. Users should be able to analyze data in its place to always have a single source of truth.

    It’s not hard to visualize that the most disruptive companies of the future will be the ones that harness data as a core asset and embed analytics in their products and services. Embedding analytics requires the right database foundation; to get to the right foundation, IT teams need to cut through the noise and study the fine print. With the proper database, the future is yours to create.

  • AWS Saves Ukraine’s Data | WPF ‘is not Dead’ (yet) | Devs Quit for Cash

    AWS Saves Ukraine’s Data | WPF ‘is not Dead’ (yet) | Devs Quit for Cash

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Amazon S3 is keeping Ukraine’s data safe, we ask if Windows Presentation Foundation is dead, and developers tell us why they switch jobs. (more…)

  • What the Convergence of Observability and Security Means for Devs

    What the Convergence of Observability and Security Means for Devs

    There is a scene in the movie Apollo 13 when the mission control flight director asks why the carbon dioxide scrubber in the command module was a different shape than the one used in the lunar module (and therefore incompatible). The engineer simply replied, “This just isn’t a contingency we’ve even remotely looked at.”

    A similar scenario plays out at many organizations when they examine security and development practices. When it’s time for code to go into production, every developer hopes their code will run as planned–smoothly and error-free. Unfortunately, something will be missed, performance could degrade or new, unanticipated problems can emerge after an application is deployed to production.

    Developers fear the “unknown unknowns.” And it keeps them up at night.

    When an “unknown unknown” problem occurs, it takes time for teams to do the forensics to identify the problem. It can take days or even weeks for teams to complete that initial investigation. If a mission-critical application is offline for a significant period of time due to a forensics investigation, then it can negatively affect your customer’s experience and, ultimately, your organization’s bottom line.

    The “unknown unknowns” problem is another challenge facing developers in today’s unpredictable macro environment. That includes the deluge of data, increasing cyberthreats, an increasingly distributed infrastructure and a remote and hybrid workforce as well as a mix of modern cloud-native and monolithic apps.

    To help developers build for the future and address security concerns, it is imperative they rethink the way they are collecting, operationalizing and storing different types of data from a variety of sources.

    Security and Observability: Better Together

    Today, security and observability have recently begun to overlap, driven by the growing need for organizations to better understand the activity inside their environments. Many forward-thinking organizations are operationalizing the massive amounts of log and event data currently being generated to understand and assess issues in their infrastructure and apps and using these actionable insights to optimize workload, app resource availability, security and uptime.

    So how can developers take advantage of the security and observability convergence trend happening right now?

    Currently, it’s common for developers to have two agents as part of their tech stack. One agent for observability, which is collecting data such as logs and events to get relevant insights into the health and performance of their application in real-time. The other agent is for security to collect data in their devtest, integration and production environments.

    Since these two agents often collect the same data, there is an opportunity to consolidate it into a single location, such as a unified security platform with a single agent, where this data can be overlaid with time series analytics to deliver relevant insights to users. Using this approach of having both security and non-security data in one place will significantly speed up the process of getting these valuable insights into the developer’s hands.

    In addition to getting insights faster, another benefit of having this data in a single location is the ability to access historical data. Giving developers the ability to store and manage data for long periods of time allows them to get insights from this historical data, so they can better understand alerts, incidents and adversaries. This can help them correlate in terms of understanding the risk to an application, such as potential “unknown unknown” threats, which they can proactively address before it causes any damage.

    Adopting a converged security and observability approach is the most mature step that organizations can take to help developers deliver the best outcomes and best experiences for their customers and users. As more organizations rely on the cloud and the speed of business rapidly increases, developers must transform their view of the health, performance and security of applications and infrastructure. Giving developers this perspective will dramatically help them take rapid action against an adverse event before it impacts their company’s bottom line.

  • What Should Business Owners Know About SSDs?

    What Should Business Owners Know About SSDs?

    Without a doubt, SSDs have become the latest trend in hardware storage, and you can expect their use to increase over time. Implementing SSDs in your business can improve productivity and make it more efficient by increasing the speed of your PC long enough to extend its useful life. Here is all you need to know about using an SSD for your business.

    What is an SSD Storage Device?

    An SSD is a storage device that functions similarly to an HDD. But instead of having moving parts, an SSD stores data on interconnected flash memory microchips that continue to store information even when there is no power flow. These microchips are known as NAND and are more reliable and faster than the HDD.

    SSDs are fast because they use the Non-Volatile Memory Express (NVMe), which allows high data exchange speeds of up to 2,600 MB/s, almost five times faster than a standard SSD. The NVMe SSDs are more recent than SATA SSDs and use the peripheral component interconnect express (PCIe).

    SSDs Vs. HDDs

    SSDs and HDDs differ in several ways, and you should understand the fundamental differences between the two. HDDs are mechanical and use magnetic heads to read and write data while spinning the platters. The number of rotations per minute determines the speed of an HDD.

    Meanwhile, SSDs are electronic and use flash memory chips, which makes them faster than HDDs. They also use NOR or NAND flash memory as their storage medium. The NAND is smaller and faster than NOR in read/write operations and can store data when off.

    What is the Lifespan of an SSD?

    Cells wear out faster when they write more data, and a standard SSD cell has a lifespan of around 3,000 write cycles, which may seem small at first glance. But the SSD uniformly distributes the write operations across all cells, reducing the chances of the cells dying and increasing the drive’s longevity.

    SSDs also have backup cells that regenerate dead cells. For this reason, large SSDs have an extended lifespan.

    How SSDs can Help Your Business: Speed, Longevity, Energy

    SSD is ideal for businesses that handle and store vast amounts of data due to its high performance, speed, and reliability. Here are more reasons why you should use an SSD for your business:

    1. Faster Read/Write Speeds
    SSDs are faster at accessing your business data, reducing the startup time for programs and operating systems. Compared to a traditional HDD, an SSD runs up to 30 times faster, allowing you to boot your PC in seconds instead of minutes.
    2. Longevity
    An SSD may be suitable for upgrading drives in a portable PC. It has no spinning drive, which means better durability and a lower likelihood of damage or losing data when you drop your business laptop.
    3. Energy Saving
    When it comes to going green and reducing energy consumption, SSD storage devices should be at the top of your list. SSDs usually generate less heat and energy since they don’t have moving parts. Therefore, you will save substantial power when using your PC, and more battery life means more productivity.

    Challenges of an SSD Storage Device

    It has always been expensive to store enterprise-level data on servers, with SSDs being slightly more expensive. As business storage capacity increases, SSDs become more expensive, and an HDD may be suitable if you want to archive a significant amount of data. Apart from archiving data, SSDs are generally the best option for storing and transferring data.

    Bottom Line: Speed, Reliability, Improved System Cooling

    Modern businesses cannot function without storage devices, and an SSD offers a unique solution that significantly increases productivity by reducing loading times. An SSD promises faster system performance, increased reliability, and improved system cooling. Due to these advantages, your business will save both time and money.

  • How to Select the Right Volume Type/Storage for Your Workload

    How to Select the Right Volume Type/Storage for Your Workload

    AWS services are at the top of the cloud services food chain, and a hot topic for nearly every business considering migrating to the cloud. Along any cloud migration journey, many hidden traps await the unprepared. The volumes you’ve already provisioned might seem like a perfect match—but are you sure they suit your workload and carry the best price for performance delivered? Today, we’ll make the difficult task of choosing a storage class for your workload a bit less complicated.

    In the World of EBS

    AWS EBS currently provides three categories of considerable storage: Hard disk drives, general purpose SSD, provisioned IOPS, and one that you will most likely never need to use—magnetic. Although I’ll provide brief descriptions of each, I’ll focus on the most widely used volume types—general purpose.

    GP Storage – the Common Choice

    This is the staple storage for pretty much all AWS users. It gives you the best bang for your buck and is commonly used for tasks that don’t require heavy lifting from a drive perspective. GP storage ranges from 1 gibibyte (GiB) to 16 tebibytes (TiB), providing from 128 to 1,000 mebibytes per second (MiB/s) of throughput, which will most probably fit your use case, unless the workload is significantly specific.

    There are multiple types of GP storage, each with different pricing and characteristics that I’ll provide a few details on below.

    GP2 – Old-Gen SSDs for the Masses

    GP2 is the typical solution for boot volumes of EC2 instances, development environments, and lighter/less important databases. This is one of the most popular options out there, although its popularity comes from old habits rather than actually being a perfect shot. GP2 volume performance scales with its size—the bigger they are, the faster they go. Still, these might seem a good option, but to be honest, they aren’t so perfect. And the biggest elephant in the room is the term you’ll have to remember – “burst credits.”

    Burst Credits – Math Homework for Your Business Work

    Provisioning a GP2 volume, you get a one-time grant of 5.4 million burst credits, which you can use to make it handle input/output better during spikes in demand. More of those tokens means you’ll be able to sustain bigger performance demand for longer, boosting your storage up to 3,000 IOPS as long as you have enough of them in your pocket.
    While depleted when you go “turbo,” they accumulate when you’re not using your disks at full speed—saving up unused performance for when you need it most. Burn them all, and your IOPS performance drops to base value and throughput falls to the baseline IOPS multiplied by max I/O size.

    The performance of GP2 storage volume can be calculated with this formula:
    Throughput in MiB/s = ((Volume size in GiB) × (3 IOPS per GiB) × (I/O size in KiB))

    Until you reach the point where your volume is so big that its base performance exceeds burstable, you’d have to learn them by heart. Where is this point? Quite high, at about 1.1 TB (1024 GiB)—a lot of disk, even for a medium-sized business, especially since those volumes can’t be mounted to multiple targets.

    Figure 1: Graph of Max IOPS available for certain volume sizes (Source: AWS documentation)

    Unless you’re deploying a disk-devouring monster such as an EC2 host instance for dozens or hundreds of Docker containers, or you plan to run an enormous Elasticsearch node for the next few years with no clean-up routines in place, you’re not likely to need this much space. Also, in either of the two cases mentioned, you’d probably run out of CPU and RAM first; there are better alternatives for these cases as well, not to mention that the lack of maintenance is definitely not a good practice.

    In addition, for practically every use case—web serving, web applications, databases, casual EC2 instances for use with Docker, and more—pretty much anything is better than GP2.

    Luckily, in 2014, the introduction of GP3 brought some great improvements.

    GP3 – The “Newcomer”

    While not really a “new” player, GP3 volumes are a welcome improvement after experiencing the inner workings of GP2. They perform better and cost less in comparison, allowing you to easily scale your operations according to your needs much easier. Gone are the days of burst credit balances.

    The golden rule of this storage class is “mix n’ match.” Baseline performance here is the maximum burst performance of a GP2 volume, 3,000 IOPS, and 125 MiB/s. If your business needs more, you can purchase additional amounts of either, paying extra only for what you’re interested in.

    The limits are quite generous. You can purchase up to 500 IOPS per GiB (for at least 32 GiB volumes, capping at 16,000 IOPS), or up to 0.25 MiB/s per GiB (for volumes of at least 8 GiB, 4,000 IOPS or more, capping at 1,000 MiB/s).

    If you were previously happy with your GP2 volume, it’s almost guaranteed your company will be just as happy with GP3, and you’ll save a decent percentage of the storage cost, even up to ~20%.

    Assuming that you don’t need more than what GP2 provided you with, make the switch. To make it even easier to cut those costs down, AWS is now automatically setting the IOPS and throughput of your new GP3 volume to the exact same as your GP2. Less guessing, less messing around, more good stuff. Just click a few buttons and save some cash, no strings attached.

    This is the storage class I would recommend for every “generic” or “typical” workload. It’s a good starting point for almost every business use case that doesn’t expect huge amounts of disk operations, but is ready to scale up when the dreaded flood of demand for disk power comes.

    GP3 can easily handle the role of boot volume for EC2 instances. It can host both simple and a bit more complex applications, databases such as MySQL and PostgreSQL, or a blend of those in a containerized environment, especially in a multi-node configuration or as part of a Kubernetes cluster. Zesty Disk for Kubernetes handles this switch automatically if you have the CSI driver installed

    When the time comes, it can scale in tandem with demand. In certain cases, it might even be cheaper to provision high-speed storage with GP3 than the IO1/IO2 types, which are dedicated to speed and next on our list.

    IO Storage Class – Need for Speed

    The IO storage class was introduced to cater to the needs of businesses based on extreme durability, high read/write speeds, and the lowest latency available. It requires certain criteria to be met to show its true potential and costs significantly more. But, in turn, it provides unmatched speeds and reliability, as well as some features you won’t find in any other storage type.

    This volume type is great if you seek a volume to provision for your high-speed disk-based database, for example, or to create a single MySQL database host for multiple large-scale e-commerce instances, although there are multiple options available for this from RDS to multi-instance DBs (e.g., MySQL Galera). It’s also a fit if you need to accept a lot of data fast to process with an ML algorithm.

    IO1/IO2 Vs. IO2 Block Express – Which Type of “Fastest” do you Need?

    IO2 Block Express is pretty much IO2 on extremely potent steroids. You get limits that are four times as high for IOPS and throughput, latency of less than milliseconds, and surprisingly, no additional fee. Yes, you read that right, they’re priced the same. Plus, provisioning additional IOPS/throughput above the limit of a standard IO2 instance actually costs less.

    If you decide to use IO2 and meet the requirements (a certain type of EC2 instance), you should definitely consider Block Express—if it’s not already running by default.

    And when would you run IO2 anyway? Well, with its power and hefty price tag, this class is dedicated to the most disk-dependent, throughput-hungry, and IOPS-dependent monstrosities. For example, a data-crunching machine for a stock exchange, a global log-ingestion mainframe, or a multi-pod Kubernetes node prepared for very demanding workloads—the titans of storage, no doubt. It’s a go-to when you need a single machine that’s going to pack as much punch as you can get.

    How about IO1 then? It’s a compromise between low latency, high IOPS, and price. A good choice when you need a bit more than general purpose, but still not enough to go for the fastest storage out there. Keep in mind there’s also one additional drawback—less durability. A 0.2% failure rate annually does not sound like a lot, but if you’re thinking about dozens or hundreds of drives, absolutely critical workloads, or both, it definitely makes a huge difference.

    So, Which Should I Choose for my Workloads?

    As you can see, the world of EBS is quite complex, to say the least. So, I made a chart that should ease the selection process for your use case:

    Fantastic Disks and How to Tame Them

    Choosing the right storage class is a tough decision to make—but the benefits are worth it. With just one shot, you can both improve the performance of your instances and save on costs as soon as your next invoice.

  • AWS re:Invent — Top 4 Things We Learned This Week

    AWS re:Invent — Top 4 Things We Learned This Week

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week, four things that caught my eye from Amazon Web Services’ re:Invent 2022 conference: SnapStart turbocharges Lambda, Graviton3E ARM HPC SoC, AWS continues hiring, and AWS’s origin story. (more…)