Cumulogic,PaaS

Docker Image for CumuLogic DBaaS for private clouds

18 Mar , 2015  

docker logoWe just released a Docker image for running DBaaS for private/hybrid clouds. Image is available on Docker Hub and can be downloaded by   running:   $docker pull cumulogic/cumulogic:v1.2

What’s included in this image?

  • This is only demo version of CumuLogic controller.
  • This is full featured version of the product and includes most of the functionality supported in current release.
  • Database engines supported are MySQL, Percona Server and MongoDB 2.x
  • Integration with Amazon Cloud, OpenStack, CloudStack private clouds.
  • Support for provisioning database instances on a pool for provisioned virtual machines or bare metal servers
  • Supports CentOS 6.x and RHEL
  • MySQL instances support:
    • Percona Clustermysql logo
    • MySQL Single node instances with capability to launch read-only replica sets on multiple zones
    • Multi-AZ instances – provisions cluster nodes across multiple zones
    • Capability to add/remove nodes and replica nodes as desired without database interruption
    • Full monitoring of system metrics as well as MySQL metrics
    • Automated failover recovery to handle failures on disk, network, VMs and zones
    • Automated snapshots and manual backups
    • Notifications on events of critical importance
  • MongoDB instances support:mongodb-logo
    • Single node MongoDB instances
    • Replicasets
    • Auto provisioning of arbiter nodes based on the topology requested
    • Sharding with or without replica sets
    • Capability to add/remove replicasets
    • Capability to add additional shards
    • Automated failure recovery of replica nodes and shards
    • Automated full backups and snapshots
    • Monitoring and performance metrics

More details are available at https://registry.hub.docker.com/u/cumulogic/cumulogic/

Drop us a line at support [AT] cumulogic [DOT] com for any questions or help with running this image.

The post Docker Image for CumuLogic DBaaS for private clouds appeared first on Platform as a Service Magazine.

, , , , , , ,

Cumulogic,PaaS

Bringing RDS Simplicity to Any Infrastructure

12 Nov , 2014  

(For those of you that read our previous post, DBaaS Service Delivery Options for Cloud Providers, this will be a similar discussion about the architectural options available to CumuLogic customers, but with an enterprise IT focus.)

There’s no questioning the adoption of DBaaS within the enterprise. It’s becoming more and more prevalent to find that at least one application team within a company is using Amazon’s RDS capability, or other DBaaS offerings from AWS and elsewhere. The fact is that the manual efforts required to properly deploy and manage a database is much greater than it needs to be. It’s also simply not adding any value to your company to spend time dealing with technology management tasks that are easily abstracted. Application teams know this (they want to focus on the valuable coding activities), and they see how easy it is to get backend data services from external providers.

The challenge for IT departments is that they need to find a way to bring some level of order to this DBaaS adoption trend. But, IT should never seek to halt progress and technology adoption. Instead, IT needs to accept change the focus on finding ways to actually embrace and extend the technologies and services that the rest of their organization are adopting. IT’s role is a dual focus on business enablement and organizational risk mitigation.

With that in mind, CumuLogic’s DBaaS software platform was designed to help IT meet that dual purpose for data services. Our software gives the enterprise IT teams a wide variety of options for how DBaaS can be employed to balance the unique risk / reward structure that’s unique to every company (and every application). This includes DBaaS deployment options like an integrated experience with your existing private cloud, an appliance-based deployment of DBaaS per application team, enterprise-controlled DBaaS on a public cloud, multi-cloud hybrid scenarios, and even bare metal DBaaS.

In this post, we’ll review the basics of the CumuLogic DBaaS Platform’s features and architecture, and then delve into the variety of DBaaS delivery models that CumuLogic makes possible for the enterprise.

If you want to hear more about the architectural flexibility of the CumuLogic DBaaS Platform, and it’s benefits for the enterprise, we’re hosting a Amazon RDS-Like Simplicity on ANY Infrastructure tomorrow (Thursday November 13) from 9:00 AM to 9:30 AM PST. We promise it will be fast and informative!

Basic Architectural Components

In order to understand how the CumuLogic DBaaS Platform is able to provide this flexibility, it’s important to start with a basic understanding of our architecture. The architecture is made up of two main components: the controller and the deployed instances.

First, let’s discuss our controller software. The CumuLogic controller (sometimes referred to as management server) is a stateless Java-based software package that exposes both a web-based user interface (for both admins and end users) and a RESTful API (again, with both administrative and user-centric functions). The controller is designed to work as a single instance, perfect for POC or appliance-based delivery, and scales horizontally to provide both higher availability and additional capacity. The controller nodes are connected to a MySQL (or compatible) database to store both configuration metadata and deployed instance monitoring data.

In order to provide maximum flexibility, the controller has been designed to support up to 20 distinct “target clouds” (more on this in a bit). A single moderately sized controller (usually deployed as a virtual machine) is capable of supporting up to 1,000 user-deployed database nodes. Critically, our controller does not sit in the data path between applications and the managed database instances that it’s managing for users.

This leads us to the deployed instances portion of the architecture. Instances are the virtual (or bare-metal) systems that are given a roll within a deployed database cluster. In the case of an IaaS-based infrastructure, deployed instances are created on-demand as users request database services. In another model, the controller is able to allocate nodes of a pre-provisioned pool of systems to receive the appropriate software required to play it’s part in a new database environment. Each deployed instance runs a basic configuration of the CentOS operating system, the specific database software required for it to play it’s role (MySQL, MongoDB, etc…), and a small CumuLogic software agent that serves as our controller’s touchpoint on that instance.

We mentioned that the controller is able to support up to 20 “target clouds”, and this is an important part of the flexibility of the platform. Our system is able to provision virtual infrastructure on any cloud environment that supports the AWS EC2/EBS, OpenStack, CloudStack or vCloud APIs. Any specific API endpoint represents a single target cloud (regardless of the size of the target). We also include support for bare-metal servers (or even pools of pre-provisioned virtual machines) as a “target cloud” that can receive the database application payloads.

So to simplify: The CumuLogic DBaaS controller uses any number of options to get the required infrastructure, and then manages deployed instances via a lightweight agent.

Integrated DBaaS / IaaS Experience for Private Clouds

Integrated DBaaS - IaaS Experience for Private Clouds - Enterprise

The most common approach for enterprise use of CumuLogic is to provide a DBaaS experience that is integrated into their larger private cloud environment. In this scenario, the controller is deployed along-side the IaaS control software. End users are given access to the DBaaS functionality through either the provider’s own UI (communicating with our controller via it’s APIs) or linked to the CumuLogic web-based UI via enterprise’s preferred SSO protocol. Also typical to these installations, enterprises will use the CumuLogic admin APIs to automatically push tenant identities to our controller. CumuLogic can also link into an Active Directory or other directory system that supports LDAP.

DBaaS on a Public Cloud

DBaaS on a Public Cloud - Enterprise

The second most common enterprise use-case for CumuLogic’s software is to use the platform to manage their own DBaaS capability on top of a public IaaS provider’s cloud. Since the CumuLogic controller is able to communicate with a number of different APIs to build the virtual infrastructure necessary to host the database instances, the enterprise gets to take advantage of the scale and diversity of the public cloud market while controlling the “higher level” database services.

DBaaS Appliance in Service Catalog for App Teams

DBaaS Appliance in Service Catalog for App Teams - Enterprise

CumuLogic offers it’s controller in a virtual appliance form-factor, which could easily be added to an enterprise service catalog. In this model, each application team would choose to deploy CumuLogic from the catalog, and be given administrative control of that system in order to allow them to self-manage the DBaaS experience within your IaaS environment. The benefit here is very low support costs for IT, but powerful DBaaS capabilities being offered directly to the application teams that want them.

DBaaS on Bare Metal or Virtual Infrastructure

DBaaS on Bare Metal or Virtual Infrastructure - Enterprise

Every single enterprise that we have spoken with deals with the reality of existing infrastructure capital investments. That means that there are huge amounts of physical and virtual infrastructure capacity in place, often under-utilized. There’s also a strong desire to provision databases on bare-metal servers. CumuLogic helps here by letting pools of pre-provisioned systems act as target infrastructure pools for DBaaS services. These systems really only have to be on the network (and accessible by the controller) in order to be allocated for user DB requests. The pre-provisioned systems don’t need database software on them ahead of time (and actually shouldn’t), since the CumuLogic controller will deploy the appropriate application payload (the correct database software) when the system is allocated to play a role in a user’s DB cluster.

Hybrid Public + Private

Hybrid Public and Private - Enterprise

Each of the previous options were focused on a single “type” of infrastructure, but enterprise adoption of cloud is clearly headed to a hybrid model. With that in mind, CumuLogic is easily able to let an enterprise use a mix of public an private clouds as infrastructure options for DBaaS deployments. Using the same DBaaS controller, application teams can have a consistent DBaaS experience almost anywhere. They can easily place their dev / test instances on a public cloud and have production in the private cloud environment.

DBaaS Across Multiple Public Clouds

DBaaS Across Multiple Public Clouds - Enterprise

For those enterprises that are moving to a model of only deploying new systems into public clouds, we also offer a compelling deployment option. With a public “only” approach, it’s easy to get pulled into the higher level services (beyond the more commoditized virtual infrastructure) of any particular public cloud. This leads to a high degree of lock-in. CumuLogic can help by acting as the DBaaS controller, but letting the enterprise use any number of different public cloud partners for the underlying infrastructure. Databases can be deployed into either (or all), and the application teams will know that they will be getting a consistent service experience across the board.

Wrapping Up

The architectural flexibility of the CumuLogic DBaaS Platform’s software gives the enterprise quite a few deployment options, allowing you to embrace the DBaaS demands of your business while easily balancing the risks and rewards inherent in any new technology decision.

Please join us for our 30 minute webinar Amazon RDS-Like Simplicity on ANY Infrastructure on Thursday, November 13, 2014 from 9:00 AM to 9:30 AM PST, or feel free to get in touch to schedule a meeting with our team!

The post Bringing RDS Simplicity to Any Infrastructure appeared first on Platform as a Service Magazine.

, , , , , , , , , , , , ,

Cumulogic,PaaS

Rapid-Fire Webinar: Amazon RDS-Like Simplicity on ANY Infrastructure

10 Nov , 2014  

Unable to attend AWS re:invent this week and looking for an Amazon-like solution for hybrid cloud environments?

CumuLogic’s Database-as-a-Service software platform has been designed to help enterprises easily deploy DBaaS on any infrastructure: public clouds, private clouds, virtual environments, or even pools of bare metal servers.

In this webinar, we will review the basics of the CumuLogic DBaaS Platform’s features and architecture, and then delve into the variety of DBaaS provisioning models.

Attend this webinar to:

  • Review six key DBaaS deployment patterns, including the pros and cons of each.
  • Quickly offer DBaaS to your application teams, including features like clustering and multi-zone replication, backup job management and performance tuning.
  • Learn how CumuLogic’s architecture provides the integration and deployment flexibility necessary to make the most of your existing investments, while looking to the future.

Speaker:

  • Chip Childers – VP of Product Strategy, CumuLogic

You can submit your questions in advance to info@cumulogic.com so we can best tailor the webinar to your needs.

We hope to see you there!

Date/Time: Thur, November 13, 9:00 – 9:30 AM PST (time zone lookup

P.S.  Can’t join us for the live event? No problem. Register here to access the on-demand version.

Featured Speaker:

 

Chip Childers

VP of Product Strategy

CumuLogic

The post Rapid-Fire Webinar: Amazon RDS-Like Simplicity on ANY Infrastructure appeared first on Platform as a Service Magazine.

, ,

Cumulogic,PaaS

Live Webinar for Cloud Providers: Six Paths to DBaaS Revenue

5 Nov , 2014  

steep-growth-aheadDatabase-as-a-Service (DBaaS) is touted by industry analysts as the fastest growing cloud-related opportunity. DBaaS gives you a multitude of different options to tailor your service delivery model to best fit your customer base, providing at least 6 different ways to generate revenue.

In this webinar, we will review the basics of the CumuLogic DBaaS Platform’s features and architecture, and then delve into the variety of DBaaS delivery models that CumuLogic makes possible.

Attend this webinar to:

  • Review the six key DBaaS service delivery patterns, including the pros and cons of each.
  • Quickly offer DBaaS to your users, including features like clustering and multi-zone replication, backup job management and performance tuning.
  • Learn how CumuLogic’s architecture provides integration and deployment flexibility, helping you fit new services into your customers’ preferred deployment model.

Speaker:

  • Chip Childers – VP of Product Strategy, CumuLogic

You can submit your questions in advance to info@cumulogic.com so we can best tailor the webinar to your needs.

We hope to see you there!

Date/Time: Thur, November 6, 9:00 – 9:30 AM PDT (time zone lookup

P.S.  Can’t join us for the live event? No problem. Register here to access the on-demand version. Or read the related blog post.

Featured Speaker:

 

Chip Childers

VP of Product Strategy

CumuLogic

The post Live Webinar for Cloud Providers: Six Paths to DBaaS Revenue appeared first on Platform as a Service Magazine.

, ,

Cumulogic,PaaS

DBaaS Service Delivery Options for Cloud Providers

4 Nov , 2014  

Service providers have a challenge: How do they provide the right cloud experience to their customers? Are they focused on providing a shared multi-tenant public cloud? Do they create private clouds for each of their customers? Are they looking to offer a blend of public and private cloud options? And most importantly, how do they provide value above the provisioning of virtual infrastructure?

At CumuLogic, we believe that Database-as-a-Service (DBaaS) has become one of the most critical components to a compelling cloud offering, alongside compute, storage and networking. It’s a rapidly growing market, and those providers that have the foresight to include database services will reap the benefits of this market demand.

CumuLogic’s DBaaS software platform gives cloud providers a wide variety of options for delivering DBaaS to their customers, options that support any infrastructure model that fits their customer’s needs. Our software allows each provider to taylor their service delivery model to best fit their customer-base, including deployment options like an integrated experience with your existing cloud, an appliance-based deployment of DBaaS per tenant, integrated private cloud experience, multi-cloud hybrid scenarios, and even bare metal DBaaS.

In this post, we’ll review the basics of the CumuLogic DBaaS Platform’s features and architecture, and then delve into the variety of DBaaS delivery models that CumuLogic makes possible.

If you want to hear more about the architectural flexibility of the CumuLogic DBaaS Platform, we are hosting a Live 30-Minute Webinar: A Multitude of DBaaS Delivery Options on Thursday, November 6, 2014 from 9:00 AM to 9:30 AM PST. We promise it will be fast and informative!

Basic Architectural Components

In order to understand how the CumuLogic DBaaS Platform is able to provide this flexibility, it’s important to start with a basic understanding of our architecture. The architecture is made up of two main components: the controller and the deployed instances.

First, let’s discuss our controller software. The CumuLogic controller (sometimes referred to as management server) is a stateless Java-based software package that exposes both a web-based user interface (for both admins and end users) and a RESTful API (again, with both administrative and user-centric functions). The controller is designed to work as a single instance, perfect for POC or appliance-based delivery, and scales horizontally to provide both higher availability and additional capacity. The controller nodes are connected to a MySQL (or compatible) database to store both configuration metadata and deployed instance monitoring data.

In order to provide maximum flexibility, the controller has been designed to support up to 20 distinct “target clouds” (more on this in a bit). A single moderately sized controller (usually deployed as a virtual machine) is capable of supporting up to 1,000 user-deployed database nodes. Critically, our controller does not sit in the data path between applications and the managed database instances that it’s managing for users.

This leads us to the deployed instances portion of the architecture. Instances are the virtual (or bare-metal) systems that are given a roll within a deployed database cluster. In the case of an IaaS-based infrastructure, deployed instances are created on-demand as users request database services. In another model, the controller is able to allocate nodes of a pre-provisioned pool of systems to receive the appropriate software required to play it’s part in a new database environment. Each deployed instance runs a basic configuration of the CentOS operating system, the specific database software required for it to play its role (MySQL, MongoDB, etc…), and a small CumuLogic software agent that serves as our controller’s touchpoint on that instance.

We mentioned that the controller is able to support up to 20 “target clouds”, and this is an important part of the flexibility of the platform. Our system is able to provision virtual infrastructure on any cloud environment that supports the AWS EC2/EBS, OpenStack, CloudStack or vCloud APIs. Any specific API endpoint represents a single target cloud (regardless of the size of the target). We also include support for bare-metal servers (or even pools of pre-provisioned virtual machines) as a “target cloud” that can receive the database application payloads.

So to simplify: The CumuLogic DBaaS controller uses any number of options to get the required infrastructure, and then manages deployed instances via a lightweight agent.

Integrated Public Cloud Experience

Integrated IaaS + DBaaS Experience

The most common approach the cloud providers take with our software is to provide a DBaaS experience that is integrated into their larger cloud service environment. In this scenario, the controller is deployed along-side the IaaS control software. End users are given access to the DBaaS functionality through either the provider’s own UI (communicating with our controller via its APIs) or linked to the CumuLogic web-based UI via the provider’s selected SSO protocol. Also typical to these installations, providers will use the CumuLogic admin APIs to automatically push tenant identities to our controller.

Single Tenant Private Cloud

Single Tenant Private Cloud

The private cloud option is really a variation on the “Integrated Public Cloud” model, but the deployment(s) are done per-customer as part of their private cloud environments. This obviously provides for customer-level tenancy to be isolated to that particular IaaS environment, with multi-tenancy at the user / department level happening within the private cloud. 

DBaaS On Another Provider’s Cloud

DBaaS on Third Party IaaS

This is one of the more novel cloud provider use-cases, given that it relies on a third party’s IaaS cloud as the underlying infrastructure for the database deployments. Since the CumuLogic controller is able to communicate with a number of different APIs to build the virtual infrastructure necessary to host the database instances, a provider has the option of offering their end users DBaaS on external public clouds.

Single Tenant Appliances on Your Cloud

DBaaS Appliance

CumuLogic offers its controller in a virtual appliance form-factor, which could easily be added to a cloud provider’s service catalog of available templates. In this model, the user would choose to deploy CumuLogic from the catalog, and be given administrative control of that system in order to allow them to self-manage the DBaaS experience within your IaaS environment.

Bare Metal DBaaS

DBaaS on Bare Metal

For some customers, there is still a strong draw to provision databases on bare-metal servers. CumuLogic supports this model, allowing a provider to provide the controller with a pool of pre-provisioned systems that only have to be on the network (and accessible by the controller) in order to be allocated for user DB requests. The pre-provisioned systems don’t have to have database software on them ahead of time, since the CumuLogic controller will deploy the appropriate application payload (the correct database software) when the system is allocated to play a role in a user’s DB cluster.

Hybrid Offering Across Clouds

DBaaS in a Hybrid Model

In reality, all of the options above can be combined into numerous combinations. One of the most obvious models is for the provider to offer both a shared multi-tenant IaaS cloud, alongside per-customer private clouds. CumuLogic can let your customers use DBaaS across both environments, using the same controller, giving a consistent experience regardless of the infrastructure selected by the users for each database instance.

Wrapping Up

The architectural flexibility of the CumuLogic DBaaS Platform’s software gives cloud providers quite a few deployment options, allowing you to taylor your DBaaS services to the infrastructure demands of your unique customer-base.

Please join us for our Live 30-Minute Webinar: A Multitude of DBaaS Delivery Options on Thursday, November 6, 2014 from 9:00 AM to 9:30 AM PST, or feel free to get in touch to schedule a meeting with our team!

The post DBaaS Service Delivery Options for Cloud Providers appeared first on Platform as a Service Magazine.

, , , , , , , , , , , ,

Cumulogic,PaaS

Live Webinar: Deploying MongoDB “as-a-service” Inside the Firewall

21 Ott , 2014  

MongoDB_LogoWith the increasing expectation of “as-a-Service” support from developers, the demand for fast and easy access to new MongoDB deployments can push an operations team to its limit. Although a wide variety of offerings are available in the public cloud, large enterprises typically have security and privacy requirements that require various degrees of on-premises control. Application teams must also be sure that their applications will reside close enough to the deployed database to reduce latency concerns.

In this webinar, we show how Cumulogic’s DBaaS Platform meets enterprise requirements, empowering developers and DBAs with self service database access, while enabling IT Ops to retain control of the underlying infrastructure for governance and security.

Attend this webinar to:

  • Learn about the benefits of operating MongoDB “as-a-service”
  • See what it takes to offer MongoDB-as-a-Service to your users, including features like sharding and replica sets, backup job management and performance tuning
  • Usage examples and complex deployment options for power users

Speakers:

  • Chris Biow – Principal Technologist & Technical Director, MongoDB
  • Chip Childers – VP of Product Strategy, CumuLogic

You can submit your questions in advance to info@cumulogic.com so we can best tailor the webinar to your needs.

We hope to see you there!

Date/Time: Thursday, October 23, 9:00 – 10 AM PDT (time zone lookup

P.S.  Can’t join us for the live event? No problem. Register here to access the on-demand version.

Featured Speakers:

Chris Biow

Principal Technologist & Technical Director

MongoDB

Chip Childers

VP of Product Strategy

CumuLogic

The post Live Webinar: Deploying MongoDB “as-a-service” Inside the Firewall appeared first on Platform as a Service Magazine.

, , ,

Cumulogic,PaaS

Live Webinar (for Service Providers): Get a Piece of the DBaaS Action!

14 Ott , 2014  

VSPP webinar revenueThe market for Database-as-a-Service (DBaaS) is growing rapidly, with 451Research estimating that over 70% of enterprises will be using it by 2016. With this adoption come new expectations from your customers, and DBaaS is rapidly becoming a “must-have” service for Cloud Providers to offer.

Fortunately, the latest release of the CumuLogic DBaaS Platform, code named “Falcon,” is designed to allow you to quickly stand up a DBaaS offering of your own.

Attend this webinar to:

  • Understand the growing DBaaS market, and what customers will be increasingly expecting from their providers
  • See how CumuLogic can help you quickly offer DBaaS to your users, including features like clustering and multi-zone replication, backup job management and performance tuning
  • Learn what’s new in our Falcon release of the CumuLogic DBaaS Platform
Date/Time: Thursday, October 16, 9:00 – 10 AM PDT (time zone lookup

P.S.  Can’t join us for the live event? No problem. Register here to access the on-demand version.

Featured Speakers:

Sandeep Patni

Co-founder & VP of Systems

CumuLogic

Chip Childers

VP of Product Strategy

CumuLogic

The post Live Webinar (for Service Providers): Get a Piece of the DBaaS Action! appeared first on Platform as a Service Magazine.

, ,

Cumulogic,PaaS

Thoughts from Couchbase Connect 2014

8 Ott , 2014  

This week our CTO, Rajesh Ramchandani, was invited to participate in a “Cloud Panel” discussion at Couchbase Connect, along with representatives from CloudSoft (Alex Heneveld) and ElasticBox (Monish Sharma).

couchbaseconnect-expo

While much of the discussion was focused on how each company’s products support rapid and easy provisioning of Couchbase Server environments, it was interesting to note how a Database-as-a-Service (DBaaS) model is distinct from more generalized provisioning automation. DBaaS (or really any “as a Service” solution) focuses on not just provisioning, but ongoing management and change activities for the deployed system. The intent of providing databases “as a Service” is to allow the consumer to work with higher level abstractions that imply management of the deployment by the service itself.

At CumuLogic, we view application deployment as a three layer model:

  1. The application itself
  2. Supporting back-end services
  3. The underlying infrastructure

Each of these layers lends itself to taking a different approach.

At the top layer, applications (be they custom written or packaged) are best approached via a provisioning automation solution. Configuration management tools, application blueprinting or virtual appliances are all potentially appropriate for your needs. This is particularly true when dealing with custom applications, for which there really isn’t an opportunity to create a utility-like service to deliver the code itself.

On the bottom layer you have the infrastructure requirements. This is a layer where we, as an industry, are closest to satisfying consumers via a utility-like approach. These days, an application’s infrastructure needs are easily met via IaaS providers themselves, or by infrastructure orchestration software like OpenStack (or even Kubernetes+Docker). There are certainly differences between each public IaaS cloud, as well as between the various software that can be employed for private cloud environments, which is why we advocate that a multi-provider framework is a necessity for application owners.

Last, we get to the middle layer, the place where databases live. Databases (and other similar “software infrastructure services”, like cache clusters and message brokers) are indeed applications that can be deployed similarly to custom application code. But is that the right approach today? We believe that this layer has evolved to the point where it needs to be consumed “as a service”. This is a natural evolutionary step, and one that has been proven to be successful within the worlds largest public cloud providers. The deployment and management of a database isn’t unique to you or your application. It’s repetitive work, and best practices are well documented.

So while it’s possible to deploy databases using the same techniques that you would for your application itself, DBaaS offers a way to skip that effort and offload both installation and management of the system to software designed for just that purpose. Application owners should focus on how they use the databases, not how they install and manage them.

We would love to hear your thoughts on this approach. Please get in touch, or feel free to request a sandbox environment to experience the simplicity for yourself.

The post Thoughts from Couchbase Connect 2014 appeared first on Platform as a Service Magazine.

, , , ,

Cumulogic,PaaS

Join the CTO Panel at Couchbase Connect… and register at no charge!

6 Ott , 2014  

couchbase connect SF

The Couchbase Connect conference, the largest Couchbase community gathering, starts today in San Francisco.

Hope you’ll join us tomorrow, Tuesday, October 7, at 10 am PT for the CTO Panel. Couchbase will moderate a discussion on how the provisioning of resources to cloud infrastructure, on-premises and public, is changing.

The panel will include industry leaders who are driving an application-centric, vendor-agnostic approach by automating and simplifying the deployment and management of enterprise applications.

Featured Speakers:

  • Rajesh Ramchandani – Founder & CTO, CumuLogic
  • Alex Heneveld – CTO, Cloudsoft
  • Monish Sharma, CTO, ElasticBox

In addition to this panel, you’ll be able to attend sessions with eBay, PayPal, LinkedIn, and more.

We hope to see you there!

P.S. Can’t join us at Cloud Connect? No problem. We’ll post the panel notes soon. Or you can watch this video to learn how to deploy Couchbase-as-a-Service on-premises.

The post Join the CTO Panel at Couchbase Connect… and register at no charge! appeared first on Platform as a Service Magazine.

,

Cumulogic,PaaS

Why A Microservice Architecture Needs DBaaS

29 Set , 2014  

The microservices architectural pattern is quickly becoming synonymous with what people consider to be “cloud native” systems. As companies are shifting to a model of cloud-first for new applications, and even re-thinking their approach for some of their core systems, the microservices approach is gaining in popularity.

While most discussion of microservices is focused on the application architecture, there is less being discussed about the impact of this architectural approach on the data persistence layer, application DBAs and how DBaaS can be a helpful component to successfully building new applications as a set of microservices. In this post, we’ll touch on some of the higher level concepts that the microservices approach implies, paying particular attention to the “data” impacts.

What’s a Microservices Architecture?

In essence, the microservices pattern is one where a software system is comprised of a number of independently deployable services, each with a limited scope of responsibility. Typically, the scope of responsibility is considered to be some particular aspect of business capability that it can own end to end. In some cases, a microservice might rely on other lower-level services to deliver its functionality, but this is less frequent than purely independent services.

The microservices architectural approach allows for each service to be developed by independent teams, scaled individually and managed as a product throughout it’s lifecycle. A well implemented microservices architecture also ensures that the overall system is able to gracefully degrade it’s functionality of one or more services are offline.

Monolithic vs Microservices Architecture

Monolithic vs Microservices Architecture

To achieve the goals of the approach, that independence and isolation needs to be provided all the way down to the data persistence layer. What good is a group of independent services if they all relied on the same database system? Having a single database for the services would leave the system with a single point of failure, and reduce the ability of each service development team to truly operate as an isolated unit.

Organizational Impacts

Conway’s Law is a particularly relevant adage worth understanding if you’re planning on adopting the microservices approach to any team-based development effort.

It says:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. (M. Conway, 1968)

What we have found in the technology industry is that not only is that statement typically true, but that tendency can be harnessed to help drive the actual architecture of a system being built. If you are structured into teams that represent the “three-tier” architecture, that architecture is the likely result of every project you embark on. Conversely, if your development organization is structured as a group of independent units, each responsible for some aspect of the software’s overall business processes, you’ll get a system architecture that reflects that organizational structure.

This isn’t to say that organizing your teams into functional units will actually result in a good example of a microservices architecture being developed (there are too many other variables like team skill, etc…), but without taking Conway’s Law into account you’ll struggle to achieve the goal. It also doesn’t necessarily require that reporting lines reflect your architectural goal. It’s quite possible to get the same organizational dynamics through a matrix management approach as well.

This type of organizational thinking is particularly new for the DBA community, who are used to being a centralized team within most companies. We posted previously about our thoughts on Reinventing the role of the DBA, and it’s particularly relevant to the microservices discussion. DBA’s need to be part of each service team. Perhaps the effort required from a DBA isn’t “full time” for a single team, so DBAs could certainly be shared across multiple service teams. What’s important is for each DBA to understand that they are helping to create an isolated system within each service, and they should resist the instinct to centralize all of the data from each team they work with into a single database.

How Database-as-a-Service Supports Microservice Development

At this point, you should understand that adopting microservices as an architectural approach for your system can imply a number of thing that impact the data persistence layer, and the teams charged with being the data custodians for your organization. Specifically:

  1. Each microservice, if responsible for storing any data, should have its own database.
  2. Independent teams may select different database technologies, based on their own needs.
  3. DBAs should focus on being data experts for the service teams, but resist the urge to centralize data into a single system.

The obvious outcome of these implications is that there will be an explosion in the number of distinct databases, potentially different database engines and an increased operational complexity. This is where Database-as-a-Service can help. A good DBaaS environment should address each of these implications directly, reducing the management and operational concerns significantly.

Self Service – Letting each service development team instantly get new database instances means that they don’t have to wait for a central DBA team to spin up a new environment.

Multi-engine Support – Having more than one database flavor in the DBaaS service catalog allows the service development teams to pick what’s right for them, without concern for burdensome organizational “standards”.

Fully Automated Operations – DBAs need to focus on helping the service development teams understand how to best work with the data they are responsible for, and a DBaaS approach to database operations significantly reduces the time they need to spend on the traditional “infrastructure-centric” aspects of being a DBA.

See How CumuLogic’s DBaaS Platform Can Help

CumuLogic’s DBaaS Platform is specifically designed to let organizations operate their own DBaaS platform, running on any infrastructure (public cloud, private cloud, or even bare metal). If you’d like to learn more about how CumuLogic could help your organization build software to be much more “cloud native”, please get in touch or request a sandbox environment to try the system for yourself.

The post Why A Microservice Architecture Needs DBaaS appeared first on Platform as a Service Magazine.

, ,