devopsy.kinsta.cloud

Tag: Infrastructure-as-a-Service

  • Dell Launches Project Apex to Deliver IT as a Service

    Dell Launches Project Apex to Deliver IT as a Service

    Dell Technologies today launched Project Apex, an initiative that promises to significantly expand its ambition to deliver IT as a service from the edge to the public cloud.

    Announced at the online Dell Technologies World 2020 conference, this initiative builds on the Dell Technologies Cloud Platform through which Dell manages IT infrastructure as service on behalf of customers.

    Sam Grocott, senior vice president of product marketing at Dell Technologies, said via a single pane of glass organizations will be able to deploy and manage application workloads running on IT infrastructure provided by Dell as well as public cloud service providers using the Dell Technologies Cloud Console, which is currently available as a public preview.

    In the first half of next year, Dell plans to roll out Dell Technologies Storage as a Service (STaaS) for on-premises IT environments, which also can be managed via the Dell Technologies Cloud Console.

    In addition, Dell is reducing the entry-level cost of its existing hybrid cloud offering built on top of Dell Technologies Cloud Platform to $47 per instance per month with a subscription, in addition to making the service available in the UK, France and Germany.

    Dell is also making a pre-approved Flex On-Demand pricing option that charges organizations on a usage basis for IT infrastructure, and has expanded its managed data protection services to include multiple public clouds.

    It’s not clear whether organizations will prefer to rely on Dell to manage their IT versus continuing to manage it themselves or rely on a third-party IT services provider. In theory, organizations will be able to invest more in application development that would eventually consume more IT infrastructure than is consumed today. However, it’s not clear internal IT organizations are prepared to cede control over IT infrastructure and applications to a single IT vendor, especially if they employ IT technologies provided by a broad spectrum of vendors.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, however, Grocott noted the number of organizations that prefer to treat IT as an operational expense has increased substantially. In addition, with more employees working from home organizations are looking for a more flexible approach to IT that is a challenge for them to achieve relying on legacy systems. To facilitate that transition, Dell is expanding the refurbishment and recycling services it makes available to customers.

    In effect, Dell is enabling a cloud operating model to be applied to all of IT regardless of where applications or IT infrastructure is deployed.

    Of course, Dell is not the only IT platform provider with such ambitions. Not only are longtime rivals in the data center expanding the scope of the managed services they provide, but every major provider of a cloud service has also expanded the reach of their offerings to include on-premises and edge computing platforms. It may be a while before this titanic struggle for control over IT plays out, but the one thing that is for certain is the way IT is consumed is changing utterly.

  • Castles in the Cloud: How to Take Your Business Kingdom Off-Prem with Confidence

    Castles in the Cloud: How to Take Your Business Kingdom Off-Prem with Confidence

    Cloud transformation requires migrating all or part of an organization’s virtual assets off-premises, typically to a public cloud.  This enables greater efficiency and cost savings, among other benefits, but it brings heightened risk as well. At the same time, many organizations moving to the cloud don’t fully understand the implications in terms of security. Consequently, successful cloud migration requires a shift in mindset.

    A Medieval Metaphor for Cloud Infrastructure

    Think of your organization as a kingdom surrounded and protected by a castle. Traditionally, this castle would be outfitted with defensive layers designed to protect the residents, the royal family and the possessions within. Protection of the castle is straightforward. A moat surrounds the castle with drop bridges in and out at strategic points (firewalls).

    In addition, guards are stationed at each entry point, conducting a thorough inspection of the people, carts and the content that they carry both in and out of the castle (IDS/IPS). The guards also check credentials at the gates and within the castle to ensure patrons are cleared for access and use of rooms and resources (IAM). The perimeter and interior walls are continuously checked for weaknesses that could introduce potential blind spots that are unguarded (vulnerability management).

    The castle has a variety of rooms, each with its own function, content and worth. Each door has a lock (AV). Within each room and the correlative hallways exist guards who check credentials, monitor the people who enter and the contents they carry, etc. (behavioral detection and endpoints). In addition, multiple other measures are in place that bolster prevention, detection and response capabilities (DLP, deception, etc.). Information from all of these sources is noted in a central location by a scribe. Guards analyze the information, looking for additional indicators of potential threats to the kingdom (SIEM) and respond accordingly.

    Comprehensively, protection of the kingdom requires an overall model and policies that accounts for new threats and tactics from rival kingdoms and thieves. Architecture of security measures are continuously updated and adaptable. In the event of an incident, the guards have designed and exercised a plan to respond. 

    Understanding the Three Different Models of Cloud 

    Clearly, this is a basic metaphor for the on-prem approach. Moving to the cloud introduces a new level of complexity to protection spread across three different models: Infrastructure as a service (IaaS), Platform as a service (PaaS) or Software as a service (SaaS).

    In the context of our castle analogy, let’s assume the castle has reached productive capacity. Neighboring rivals are creating competitive pressures, offering residents (who pay taxes) the possibility of a better life if they relocate. To keep residents happy, productivity requires expansion beyond castle walls. As production expands, neighboring kingdoms offer different models to achieve productivity. However, each model presents different levels of shared responsibility in protection (referred to as the Shared Responsibility Model).

    • IaaS: In this model, the on-premises kingdom (kingdom A) decides to expand all operations to a neighboring castle (kingdom B). The castle itself and the moats are all controlled and provided by kingdom B. However, the infrastructure, moats, hallways, rooms, access lists, monitoring of activity and protection and usage of its contents are the responsibility of kingdom A.
    • SaaS: Kingdom A decides to have blacksmithing conducted in a neighboring castle (kingdom B). The castle itself, the moats, infrastructure, hallways and blacksmithing room are all protected by kingdom B for a charge. Kingdom B’s responsibility is to control access to the room, but maintaining who’s on the access list to the room and the protection of its contents and usage are the responsibility of kingdom A.
    • PaaS: Kingdom A decides to house and build military operations in a neighboring castle (kingdom B). Kingdom B is responsible for the basic controls, but the configuration and monitoring remain the responsibility of Kingdom A.

    With this transformation, Kingdom A faces a more complex security landscape. Innovation and efficiency are critical to meeting the growing and changing demands of their kingdom, but not without additional risks. New operating models bring new risks and potential vulnerabilities to their system(s). Methodologies and processes used to secure their own kingdom do not necessarily work or apply to protecting their new partner kingdoms. Additionally, people–and experience–that understand these new complexities are harder to come by while the thieves and rival kingdoms discover vulnerabilities and weaknesses and begin to exploit and steal valuables that put the entire kingdom and its residents at risk.

    Protecting Your Castle in the Cloud Takes a Deep Understanding

    Moving to the cloud is almost inevitable at this point, and it carries so much potential to accelerate business outcomes. It takes a different mindset to secure it than what we are used to as an industry–the landscape has been changed from a security perspective. By fully studying and understanding the differences, organizations can continue rapid and secure adoption of the cloud, while reaping the benefits that it promises to bring.

    — Sean Blenkhorn

  • With a Multicloud Infrastructure, Control is Key

    With a Multicloud Infrastructure, Control is Key

    Ask any developer or DevOps manager about their first experiences with the public cloud and it’s likely they’ll happily share some memories of quickly provisioning some compute instances for a small project or new app. For (seemingly) a few pennies, you could take full advantage of the full suite of public cloud services—as well as the scalability, elasticity, security and pay-as-you-go pricing model. All of this made it easy for teams to get started with the cloud, saving on both the IT budgets and infrastructure setup time. Public cloud providers AWS, Azure, Google Cloud, Rackspace and others made it easy to innovate.

    Fast forward several years and the early promise of the cloud is still relevant: Services have expanded, costs have (in some cases) been reduced and DevOps teams have adapted to the needs of their team by spinning up compute instances whenever they’re needed. But for many companies, the realities of their hybrid-IT infrastructure necessitates support for more than one public cloud provider. To make this work, IT Ops needs a control layer that sits on top of their infrastructure, and can deliver applications to customers over any architecture, including multicloud. This is true, no matter what the reason teams need to support multi-cloud environments.

    Prepare for the Worst

    As any IT Ops manager, or anyone who has lost access to their web app knows, outages and cloud service degradation happen. Modern Ops teams need a plan in place for when they do. Many companies choose to utilize multiple public cloud providers to ensure their application is always available to worldwide customers, even during an outage. The process of manually re-routing traffic to a second public cloud in the event of an outage is cumbersome, to say the least. Adding an app delivery control plan on top of your infrastructure allows companies to seamlessly and automatically deliver applications over multiple clouds, factoring in real-time availability and performance.

    Support Cloud-driven Innovation

    Ops teams often support many different agile development teams, often in multiple countries or from new acquisitions. When this is the case, it’s likely that the various teams are using many architectures on more than one public cloud. Asking some dev teams to switch cloud vendors is not very DevOps-y. A better option is to control app delivery automation with a cloud-agnostic control plane that sits on top of any cloud, data center or CDN architectures. This allows dev teams to work in their preferred cloud environment, without worrying about delivery.

    Avoid Cloud Vendor Lock-in

    Public cloud vendors such as Amazon Web Services or Microsoft Azure aren’t just infrastructure-as-a-service (IaaS) vendors, they sell (or resell) products and services that could very well compete with your company’s offering. In the beginning, using a few cloud instances didn’t seem like such a big deal. But now that you’re in full production and depend on one of these cloud providers for your mission-critical app, this no longer feels like a great strategy. Adding a second public cloud to your infrastructure lessens your dependence on a single cloud vendor who you may be in “coopetition” with.

    Multiple-vendor sourcing is a proven business strategy in many other areas of IT, giving you more options during price and SLA negotiations. The same is true for IaaS. Cloud services change often, as new services are added or removed, and price structures change. Taking control over these changes in public cloud service offerings, pricing models and SLAs is another powerful motivator for Ops teams to move to a multi-cloud architecture. An application delivery automation platform that can ingest and act on cloud service pricing data is essential.

    Apps (and How They’re Delivered) Have Changed

    Monolithic apps are out. Modern, distributed apps that are powered by microservices are in. Similarly, older application delivery controllers (ADCs) were built for a static infrastructure world, before the cloud (and SaaS) were commonly used by businesses. Using an ADC for application delivery requires a significant upfront capital expense, limits your ability to rapidly scale and hinders the flexibility to support dynamic (i.e. cloud) infrastructure. Using ADCs for multiple cloud environments compounds these issues exponentially. A software-defined application delivery control layer eliminates the need for older ADC technology and scales directly with your business and infrastructure.

    Regain Control

    Full support for multicloud in product may sound daunting. After all, Ops teams already have plenty to worry about daily. Adding a second cloud vendor requires a significant ramp-up period to get ready for production-level delivery, and the new protocols, alerts, competencies and other things you need to think about. You can’t be knee-deep in the details of each cloud and still manage infrastructure. Adding in the complexity of application delivery over multiple clouds can be a challenge, but much less so if you use a SaaS-based application delivery platform. With multicloud infrastructure, control is key.

    About the Author / Andrew Marshall

    Andrew Marshall is the Director of Product Marketing for Cedexis, and has driven product marketing efforts at New Relic, Amazon Web Services and Microsoft. Connect with him on LinkedIn.

     

  • Should You Go ‘Serverless’? The Pros and Cons

    Should You Go ‘Serverless’? The Pros and Cons

    The popularity of the “serverless” term started to grow when Amazon launched AWS Lambda in 2014. Ever since, we’ve seen the term exponentially grow in use and reference, with more vendors entering the market with their own solutions (Azure recently went GA with Functions, for example).

    What is it all about and how does this new trend affect the way people write and deploy applications? Is “serverless” a paradigm shift or just a natural evolution of infrastructure as a service (IaaS) and platform as a service (PaaS)? In this post, I will discuss what “serverless” is and is not—and how it shapes up in comparison to existing PaaS solutions.

    What is ‘Serverless’?

    “Serverless” denotes a special kind of software architecture in which application logic is executed in an environment without visible processes, operating systems, servers or virtual machines. It’s worth mentioning that such an environment is actually running on the top of an operating system and uses physical servers or virtual machines, but the responsibility for provisioning and managing the infrastructure belongs entirely to the service provider. Therefore, a software developer focuses on writing code.

    In other words, a developer thinks in terms of services or functions that communicate with each other and with the external world. After implementing these services, developers using a traditional approach would combine them into a number of distributed processes when installing, running, monitoring and updating such processes for specific operating systems that are running on specific servers or virtual machines. In the “serverless” approach, a third-party service provider is responsible for everything from the processes to the operating systems to the servers.

    When a third-party service provider is responsible for the underlying IT infrastructure, a developer no longer is in charge of purchasing a dedicated server or virtual machine. At the same time, the service provider is free to decide how to efficiently utilize its infrastructure to serve requests from all of its clients. As a result, the service provider is not usually required to run a permanent workload for a specific client; instead, the software handles requests from all of the customers at the same time, spending just a limited time on handling each request from a specific customer. Therefore, such providers usually charge their customers based on the total number of requests, the frequency of requests over a specified period or the total time spent to serve all of the requests from a customer.

    The same approach works well for different types of loads because third-party service providers usually have elastic, scalable services. When customers start using a third-party service, the expected number of requests can be low and customers pay significantly less compared to purchasing, configuring and managing their own infrastructure on-premises or in the cloud. For a larger number of requests—either expected or unexpected load peaks—customers do not need to add servers to horizontally scale their application. Instead, a service provider does care about increased load. For sure, handling a bigger number of requests will cost more, but in most cases it is still more efficient than using a dedicated IT infrastructure.

    BaaS and FaaS

    Two approaches that often are mentioned together with serverless are backend as a service (BaaS) and function as a service (FaaS).

    BaaS

    The growing number of third-party services that implement required functionality, provide server-side logic and manage their internal states has led to applications that do not have application-specific, server-side logic and use third-party services for everything. In this respect,  such applications are serverless.

    Some examples of third-party services include identity and authentication as a service (Auth0, AWS Cognito), logging as a service (Loggly, Logsense, Amazon Elasticsearch Service) and analytics as a service (Amazon Kinesis, Keen IO).

    FaaS

    When an application still requires specific server-side logic, a developer can use a modern alternative to traditional architectures: FaaS. With this approach, a developer focuses on implementing short-living stateless functions that are triggered by events and can communicate with each other and the external world. A FaaS provider does the rest—provisioning as many instances of such functions as necessary to handle all of the requests, terminate instances that are no longer required, monitor all of them and provide identity and logging services. FaaS ideally fits with microservices architecture because the FaaS provides everything that an organization needs for running microservices.

    Auth0 Webtask, AWS Lambda, Google Cloud Functions and Azure Functions are examples of FaaS implementation. IronFunctions is an ambitious initiative from Iron.io that is targeted to run AWS Lambda functionality on the most popular cloud providers as well as on-premises.

    What is Not ‘Serverless’?

    The main difference between serverless and PaaS is that traditional PaaS providers such as Heroku or OpenShift usually lack the automatic scaling feature. A user of traditional PaaS has to specify the amount of resources—such as dynos for Heroku or gears for OpenShift—for the application. It still is possible to manually scale the application up or down by changing the number of assigned resources, but mostly this is the responsibility of a developer or system administrator.

    The second difference is that traditional PaaSes are designed for long-running server applications. With such a design, the application always should be running to serve incoming requests. If you bring the application down, it obviously will not serve the requests. With FaaS, your function starts to serve a request and terminates when the request is processed. Ideally, your functions should not consume provider resources when there are no incoming requests (see also “cold start” issue below).

    Traditional PaaS implementations are not “serverless” under the strict definition of this term because they do not have automated scaling and require that server-side applications are always running so that requests can be served. Traditional container management platforms are not “serverless” for the same reasons.

    Another way to know if a provider allows the serverless approach is to identify the border between two areas of responsibility: the provider’s consumer and the provider itself. In “serverless,” the border is between application code and how is this code is actually deployed and running on physical servers. In container platforms, a platform’s consumer is still responsible for working with the operating-system level to define things such as the processes that will run in which containers and how many containers of each kind will run.

    Nonetheless, there is an inherent similarity between containers and serverless. For example, Kubernetes—an open-source container orchestration platform—allows for the automated scaling of containers using application-provided metrics such as the number of concurrent requests. AWS Lambda actually runs a container for each function.

    In other words, containers and container orchestration may provide an efficient way to implement FaaS while FaaS provides an additional abstraction level that hides specific processes, operating systems and containers from developers and allows them to focus on code.

    The Benefits and Drawbacks of “Serverless”

    As we already mentioned, “serverless” has the following main benefits:

    • Reduced time to market and quicker software release.
    • Lower operational and development costs.
    • A smaller cost to scale – there is no need for developers to implement code to scale and administrators do not need to upgrade existing servers or add additional ones.
    • Works with agile development and allows developers to focus on code and to deliver faster.
    • Fits with microservices, which can be implemented as functions.
    • Reduces the complexity of software.
    • Simplifies packaging and deployment and requires no system administration.

    At the same time, “serverless” has the following drawbacks:

    • Serverless is not efficient for long-running applications. In certain cases, using long tasks can be much more expensive than, for example, running a workload on a dedicated server or virtual machine.
    • Vendor lock-in. Your application is completely dependent on a third-party provider. You do not have a full control of your application. Most likely, you cannot change your platform or provider without making significant changes to your application. Also, you are dependent on platform availability, and the platform’s API and costs can change. Needles to say, the existing FaaS implementations are not compatible with each other.
    • Serverless (and microservice) architectures introduce additional overhead for function/microservice calls. There are no “local” operations; you cannot assume that two communicating functions are located on the same server.
    • To utilize its resources more efficiently, a service provider may run software for several different customers on the same physical server (this is also known as “multitenancy”). Even if customers’ workloads are isolated in virtual machines or containers, there can be different bugs in the early stages of FaaS offerings. This can be a major security issue for your application if you work with sensitive data. Such potential bugs in a platform or failures in one customer’s code (a “noisy neighbor”) can affect the performance or availability of your application.
    • In practice, it takes some time for a scalable serverless platform to handle a first request by your function. This problem is know as “cold start”—a platform needs to initialize internal resources (AWS Lambda, for example, needs to start a container). The platform may also release such resources (such as stopping the container) if there have been no requests to your function for a long time. One option to avoid the cold start is to make sure your function remains in an active state by sending periodic requests to your function.
    • Some FaaS implementations—such as AWS Lambda—do not provide out-of-the-box tools to test functions locally (assuming that a developer will use the same cloud for testing). This is not an ideal decision, especially considering that you will pay for each function invocation. As a result, several third-party solutions are trying to fill this gap, enabling you to test functions locally.
    • Different FaaS implementations provide different methods for logging in functions. For example, AWS Lambda allows writing logs to AWS CloudWatch using the standard frameworks for the specific language (Log4j for Java, console methods for Node.js, logging module for Python). It is completely up to the developer how to implement more advanced logging.

    Summary

    Serverless architecture is a new approach to writing and deploying application that allows developers to focus on code. Such an approach can reduce time to market, operational costs and system complexity. While serverless leverages third-party services such as AWS Lambda to eliminate the requirement to set up and configure physical servers or virtual machines, it also locks in the application and its architecture to the specific service provider. In the future, we can expect more movement toward the unification of FaaS APIs or frameworks such as IronFunctions that will help to avoid vendor lock-in and enable us to run serverless applications on different cloud providers or even on-premises.

    — Asaf Yigal

  • Azure vs. AWS for the Enterprise

    Azure vs. AWS for the Enterprise

    In a previous post we discussed Azure & OpenStack, the less-explored hybrid cloud, and we thought we’d segue on the hybrid cloud theme, and follow up with an additional post focusing on a question we’re often asked …

    Azure or AWS?

    It’s one of the most common questions enterprise customers today face as they look to go to the cloud. According to this year’s Gartner’s Magic Quadrant report, the two cloud powerhouses are the clear market leaders, and as they each add new services to their arsenal and expand their service offerings, customers must decide which one is best-suited for their business needs. This, of course, is in the context of public cloud, whereas the question of OpenStack vs. VMware usually arises in the context of private cloud. And with reports popping up all the time that demonstrate growing numbers around every hybrid cloud mix-and-match scenario, many enterprises are debating on what to bet their cloud strategy.

    To begin this comparison, it’s important to understand how each has evolved. Azure was built as a holistic platform and has been geared toward the enterprise from the beginning. It began as a platform as a service (PaaS), making it easier for developers to build applications without worrying about the servers on which they’re running. In addition, part of the Azure approach always has been to think about how to integrate each service to the platform as a whole and support enterprises’ IT flexibility with keeping specific workloads on-premises while complementing their IT requirements with services running on the cloud.

    AWS, on the other hand, started scaling from the infrastructure from the beginning. Its approach has been to continually be ahead of the innovation curve and offer services that IT operations can easily comprehend and use to support their compute and storage requirements on demand.

    Market Share Comparison: The Path to Growth

    It’s not hard to see why both AWS and Azure have grown into their roles as the market leaders. Today more than 70 Amazon services can be utilized, including the basic compute, storage and network building blocks, as well as “up the stack” services such as database as a service and even frameworks to easily scale mobile applications, databases and more. AWS has a massive public cloud with the largest data centers in the world, and excels at allowing their customers to choose the building blocks they need to create a variety of service offerings.

    That said, Azure is growing as well, and quickly gaining ground on AWS. Microsoft has moved aggressively to match AWS by enhancing and building up its array of offerings. The company has been selling to the enterprise market for decades and, as a result, has garnered strong relationships with many large global organizations. These efforts and relationships seem to be paying off, as a recent survey of 100 CIOs by Morgan Stanley predicted that Azure would be the largest infrastructure-as-a-service (IaaS) vendor by 2019.

    Enterprise-Grade Product Capabilities

    AWS and Azure both provide comprehensive enterprise cloud services, and they both do it well. The core features of AWS include a large suite of infrastructure and application services that enable running nearly everything in the cloud, from traditional enterprise applications to large web-scale workloads. AWS is the clear winner these days in terms of the number of services it offers; the services are well-connected and provide full cloud capabilities for most enterprise needs.

    Azure is also fast closing the gaps with the enterprise cloud market, including with large-size virtual machines, StorSimple Virtual Array, itsNAS offering and the SQL Data Warehouse. In addition, with its recent announcement of Azure Stack, and via solutions such as Cloudify, Microsoft strengthens hybrid architecture and workload mobility between on-premises and public cloud workloads.

    Other factors that are driving enterprises to adopt Azure include the Azure Security Center (ASC), which provides a centralized view of security policies and configurations from multiple Azure subscriptions; the ability for customers to save time and effort through unified operations tools such as SQL Manager, Visual Studio and other such services; and seamless VM migration to migrate servers between disparate environments.

    Growth Strategies

    Microsoft also plans to invest heavily in cloud growth going forward, with a big push and investment in new features and infrastructure. Microsoft’s Intelligent Cloud unit continues to be the focal point of the company’s growth strategy, as the company claims that nearly 60 percent of Fortune 500 companies use at least three of Microsoft’s cloud offerings.

    Both AWS and Azure, in fact, are investing heavy capital expenditures on worldwide data centers and servers. AWS, for example, has just announced a new Asia Pacific region in Mumbai, India, with two availability zones. And with the introduction of new regions in the U.K., Microsoft has announced 34 Azure regions around the world, with 28 generally available today—more than any other major cloud provider. With certifications such as MCSE and many more, Microsoft has more certifications than any other cloud provider in the industry.

    Both AWS and Azure are poised to continue growing, and both companies have big futures in the cloud market. It’s clear, however, that in the cloud game today, Azure is narrowing the functional gap. Azure gives enterprises the ability to use existing Microsoft software licenses under the Enterprise Agreement (EA), giving enterprises better terms and packages. Microsoft enterprise users are potentially ‘power users,’ and prefer a DIY approach versus pre-packaged and opinionated options. This leaves the market open to more collaboration, such as through the use of Docker Swarm. With this type of approach, users have control over the way they run their apps on various platforms, with open-source orchestration to allow consistent management and control of their applications and services.

    — Sharone Zitzman

  • Financial Drivers for Cloud Migration in Enterprise

    Financial Drivers for Cloud Migration in Enterprise

    Clouds are a vast pool of usable and manageable virtualized means such as development platforms, hardware and services. These assets can be animatedly reconfigured to adjust to a flexible load, which helps in the optimal utilization of resources. Your enterprise breathes through IT—to keep your business moving forward, you must modernize and be more flexible to break the shackles of the orthodox technologies that are holding you back.

    The cloud’s pay-as-you-go business model enables enterprises to cut capital spending by leveraging the cloud service. It also offers several benefits required by the enterprise, including lower operating cost, no upfront investment, great scalability and much more.

    To gain the benefit of cloud computing and guard the current investment to the legacy system, companies are keen in migrating their legacy systems to the cloud. The cloud provides a cost-effective corridor to transforming legacy systems to more modern technologies. It offers modern efficient development structures, improved supervision of IT resource supply and demand and enhanced scalability, and it provides access to these assets from almost any part of the world. With this upgraded dexterity, you are able to respond more swiftly to the changes in the market, exploit newer business prospects, surge financial growth and drive innovation.

    However, to benefit from what the cloud could offer, you are required to spend money and time on launching your cloud and migrating data and applications to the newer environment.

    Migrating databases from on-premise machines to the cloud has a few crucial advantages: Cloud elasticity delivers instant flexibility in scaling up or down. And, the cloud model saves money by shifting companies from early heavy capital expenses (CapEx) of on-premise hardware to constant, known operational expenses (OpEx) on cloud facilities and more.

    Migration Ahoy

    But migrating live applications to the cloud is not an easy task. Listed below are few methods to migrate to the cloud.

    Rehost: This term refers to redistributing applications to a diverse hardware setting and changing the application’s structure configuration. Rehosting the application while making no changes to its construction can offer a faster migration to the cloud. The key benefit of infrastructure as a service (IaaS) is that the systems can be migrated by the teams quickly, with no modification to their architecture.

    Refactor: This term refers to applications run over the cloud provider’s infrastructure. The main benefit is combining innovation with awareness, as “backward-compatible” platform as a service (PaaS) means developers can reuse frameworks, languages and containers in which they have invested. Its biggest drawbacks include transitive risk, missing capabilities and lock-in framework.

    Revise: This method requires extending or modifying the present code base to assist the legacy transformation requirements, and then using the refactor or rehost options to position the cloud. This method enables enterprises to enhance the application to influence the cloud features of providers’ infrastructure. However, this method requires upfront development work, which needs upfront outlays to assemble a development team.

    Rebuild: This term refers to rebuilding the solution on PaaS, discarding code for the current application and restructuring the application. Though rebuilding involves dropping the familiarity of present code and frameworks, the benefit of rebuilding the application is admission to advanced and innovative features in the platform of the provider. They increase the productivity of the developer. Still, lock-in is a major drawback: Should the provider make a pricing or technical change, breaches the service level agreements or goes out of business, the customer is required to switch, possibly deserting some or almost all its application resources.

    Replace: This method requires discarding the present application and using the commercial software offered as a service. This method reduces or eliminates any investment in assembling a development team when there is a change in the business function. Issues may include issues in accessing the data, unpredictable data semantics and vendor lock-in.

    The Bottom Line

    Projects relating the migration be of any size entails careful planning. Evaluating its existing applications portfolio could help an organization understand the complexity, challenges and amount of effort required in migrating its databases to the cloud. Many tools assist application and database migrations, and each method differs in the amount of automation they provide and in the accurateness of the migrated system. Carrying out proofs of concept using these tools to understand their abilities will be constructive in the longer run for larger projects related to migration.

  • ProfitBricks shakes things up with new Docker hosting platform

    ProfitBricks shakes things up with new Docker hosting platform

    Organizations and developers that want to leverage Docker containers have a variety of cloud platforms to choose from. Rackspace, Amazon, Azure and others all support Docker containers. There’s also a relative newcomer in the mix looking to shake things up.

    ProfitBricks is an infrastructure-as-a-service (IaaS) company that believes it has a unique value proposition for companies that want to take advantage of cloud infrastructures and Docker container technology. ProfitBricks was co-founded by its CEO, Achim Weiss, and its CMO, Andreas Gauger. The two previously founded the Web hosting service 1&1 Internet.

    Weiss and Gauger launched ProfitBricks four years ago to solve a perceived problem. They saw the value of cloud infrastructure and cloud services, but felt that the existing platforms suffered in the areas of performance, flexibility, usability and cost. So ProfitBricks was born.

    ProfitBricks claims to have more speed and provide better value compared with rival cloud platforms. It calls its platform Cloud Computing 2.0.

    ProfitBricks Docker Hosting

    Docker has become a household name virtually overnight—quickly establishing itself as the de facto standard for container technology. David Bartletti, a principal analyst for Forrester, recently wrote in a research report, “Docker helps developers package code for quick assembly and hand-off to quality assurance, testing, and production release teams with greater confidence that their app will run consistently as it moves through the release process…The Docker open source community is growing quickly, with strong representation from nearly every major cloud vendor…As Docker containers proliferate, developers and operations teams alike will demand management tools that help organize and orchestrate hundreds or thousands of containers.”

    With so much momentum behind Docker and container technologies, it makes sense for a cloud infrastructure provider to integrate Docker into its ecosystem. Last week ProfitBricks announced its new Docker hosting platform. The platform features dedicated resources, redundant block storage, and 80 Gbps networking. It allows developers to choose images, link containers, and expose ports. The free tier offers customers 2,500 CPU Core hours as part of the Early Access Preview with up to 4 CPU cores, 8 GB of RAM, and 100 GB of storage.

    “When we first embarked on our Docker product architecture, we knew that it would not only need to meet the standards of existing Docker platforms, but also incorporate new, industry-leading features that addressed existing problems encountered with Docker,” said Achim Weiss, co-founder and CEO of ProfitBricks, in a press release. “Docker has been taking the DevOps world by storm since its widespread introduction to the community in 2014, and our platform will combine its impressive features with our flexible and painless cloud computing infrastructure.”

    ProfitBricks says that one thing that sets its Docker hosting apart from the competition is autoscaling. The ProfitBricks cloud infrastructure will ensure that resources are automatically managed to meet the demands of the Docker containers running on it. Developers don’t need to rely on standalone applications or custom scripts to scale resources because those capabilities are integrated seamlessly into ProfitBricks.

    ProfitBricks claims to be the best value in cloud computing. It offers a bold promise for the price / performance ratio on its site. “We guarantee that any workload deployed on ProfitBricks will cost less than the same workload running at the same performance level on the IaaS platforms of Amazon, Google or Microsoft.”

    You can check out the new ProfitBricks Docker Hosting for yourself. Visit this link for an Early Access Invite and find out if ProfitBricks can really deliver.

  • Equalizing IT infrastructure with DevOps

    Equalizing IT infrastructure with DevOps

    IT is getting more complex. Managing on-premise servers, cloud servers, and hybrid environments that span various operating systems and standards creates challenges for IT admins. DevOps technologies and platforms, however, can be an equalizing force among the cloud chaos—making it easier for organizations to deploy servers and applications quickly and consistently regardless of platform or environment.

    Once upon a time most organizations were fairly standardized. Servers were located on-premise in some sort of closet or data center, and IT admins knew exactly what operating system they were working with. Now, those servers may be physical or virtual, on-premise or in the cloud, Windows or Linux, Azure or Amazon, and in many cases IT admins are dealing with an infrastructure that amounts to an all-of-the-above approach.

    As the name implies, the core of the DevOps movement is to remove the barriers between developers and operations. Many of the tools and technologies that comprise the DevOps movement, however, also have the added benefit of providing a consistent, modular approach to developing and deploying applications and infrastructure. Those technologies also reduce friction between on-premise and cloud environments, and allow organizations to streamline operations across different platforms and operating systems.

    “One of the biggest reasons for the increased interest in DevOps tools and practices is because businesses have to move and iterate faster today than at any other time in history,” declared Tim Zonca, director of product marketing for Puppet Labs. “So IT teams are pursuing DevOps flows, where development and operations practices, systems, and tools work in lockstep.”

    As IT infrastructures become more complex, DevOps becomes more crucial. Expansion of IT across physical, virtual, and cloud environments make even minor inconsistencies into critical issues as organizations grow, and brings additional burden to address those problems.

    Many DevOps technologies revolve around using virtualization to deploy applications inside pre-built environments, or modular blocks that can be deployed and re-used across various platforms and environments. These tools remove most of the chaos, and enable organizations to simplify deployment across virtually any infrastructure.

    Docker is a great example of the impact DevOps is having. Docker containers enable developers to package an application, and transport it anywhere Docker containers are supported without modification to the virtual environment. As Docker continues to spread influence across Azure, Parallels, and other cloud and virtual platforms, it is asserting itself as an equalizing force that eliminates the need to even care what the underlying infrastructure or operating systems are.

    Puppet Labs is another illustration of the equalizing force of DevOps. Zonca explained, “Puppet makes it easy to standardize and add consistency to your infrastructure so you can make fast, repeatable changes across physical and virtual machines, on premises or in the cloud. Because these tools create a predictable environment, you don’t have to worry about a simple update taking down an entire system your business relies on.”

    James Bottomley, CTO of server virtualization for Parallels, suggests that even DevOps has its limitations, though, and that it could eventually get in the way of advancing productivity. “However, one cannot help thinking that DevOps, while a leveler, is also a separator because it is only accessible to developers with the Ops skill, not to all developers. Additionally, the utility of DevOps depends upon the availability of Infrastructure and, while IaaS is clearly the dominant Cloud technology today; it won’t be forever. At that point, one might imagine that the DevOps technique might impede rather than assist the next paradigm shift in the cloud.

    For now at least, DevOps technologies enable developers and IT admins to take a modular, platform-agnostic approach to many aspects of applications and infrastructure to simplify and streamline regardless of the underlying environments or operating systems.