What you will need before you get started :
What you will need before you get started :
We partner with solution integrators specializing in cloud consulting & delivery so although we at Cloud A do not bid on RFP’s directly, we would of course be more than happy to partner with organizations looking to leverage true cloud solutions in Canada. Our partners have helped over 400 organizations achieve their strategic objectives by migrating to Cloud A over the past 15 months. As a result, together we have a deep understanding of the approach and cultural shift required to realize successful change in this new era of computing.
This article hopes to clarify some of the considerations and actions to take when preparing an RFP to maximize the potencial benefits cloud computing has to offer. The goal of this article is to make the RFP attractive to the leading cloud providers and solution integrators from whom you are seeking submissions. There are many factors that are different to your traditional hardware and application requests of the past. Simply, the cloud is a new realm in computing with a lot to know and there are many other folks out there repackaging old tech as “cloud” these days; that is something you need to be careful of. Read more
Migrating your application from Heroku to Cloud 66 involves deploying your code, importing your data and redirecting your traffic to the new endpoint.
Using Heroku, you can choose between 1X (512 MB), 2X (1 GB) and PX (6 GB) server sizes. This makes it easy to calculate your server requirements, and we recommend that you use similar server resources when deploying your stack with Cloud 66. We also recommend that you have a separate server for your database in production environments.
Simply provide Cloud 66 the URL to your Git repository so that it can be analyzed. For more information, seeAccessing your Git repository.
Once your code is deployed, it’s time to migrate your data across. The process differs for PostgreSQL and MySQL databases:
From your Heroku toolbelt, create a database backup URL by running heroku pgbackups:url. Next, visit your stack detail page and click the Import Heroku data link. Paste the URL provided by the toolbelt into the field, and click Import Heroku data.
Start by dumping your existing database. Refer to the ClearDB documentation for common problems.
$ mysqldump -u [username] -p[password] [dbname] > backup.sql
Once you have a MySQL dump file, use the Cloud 66 toolbelt to upload the file to your stack database server. Remember to replace the fields below with your values.
$ cx upload -s "[stack_name]" [database_server_name] backup.sql /tmp/backup.sql
Next, use the toolbelt to SSH to your server.
$ cx ssh -s "[stack_name]" [server_first_name]
Finally, use the command below to import your backup into the database. You can find the generated username, password and database name by visting your stack detail page and clicking into your database server (eg. MySQL server).
$ mysql -u [generated_user_name] -p [generated_password] "[database_name]" < /tmp/backupfile.sql
Once you’re ready to serve traffic from your Cloud 66 stack, you need to redirect your traffic to it. For more information, see Configure your DNS.
By default, Cloud 66 will deploy your stack with Phusion Passenger, but you can also choose acustom web server like Unicorn. You may have a web entry in your Procfile to do this on Heroku. Cloud 66 ignores this entry to avoid compatability issues.
To run a custom web server, we require a custom_web entry. It is important to set this before analyzing your stack, to avoid building the stack with Passenger.
You can also use the Procfile to define other background jobs.
Heroku restarts all dynos at 24 hours of uptime, which may conceal possible memory leaks in your application. When you migrate to Cloud 66, these will become noticeable because we don’t restart your workers (other than during a deployment), so the leak can grow to be bigger. A temporary solution is to re-create the Heroku restart behavior, for example with this script:
for OUTPUT in $(pgrep -f sidekiq); do kill -TERM $OUTPUT; done
This will send a TERM signal to any Sidekiq workers, giving them 10 seconds (by default) to finish gracefully. Any workers that don’t finish within this time period are forcefully terminated and their messages are sent back to Redis for future processing. You can customize this script to fit your needs, and add it to your stack as a shell add-in.
Note that this is a temporary solution, and we recommend that you use a server monitoring solution to identify the source of your leak.
If you haven’t compiled assets locally, Heroku will attempt to run the assets:precompile task during slug compilation. Cloud 66 allows you to specify whether or not to run this during deployment.
Probably the simplest step in the whole process is ensuring that your application is Canadian data resident. You will need to create an account with Cloud-A. Then when you set up your stack on Cloud66 ensure that you select Cloud-A as your cloud provider of choice.
We are happy to announce our partnership with Cloud 66, a leading provider of Devops-as-a-service, giving you everything you need to deploy, scale and protect your applications on Cloud-A in a single tool.
This partnership allows Cloud-A users to deploy and manage their applications more efficiently than ever before, offering one click, automated functionality for managing the lifecycle of your entire stack on Cloud-A which allows developers to do what they do best.
This partnership is part of an ongoing effort to provide Cloud-A users with world class tools to run their workflows on our high performing, secure, Canadian resident cloud servers.
Visit our Cloud 66 solutions page here for more details.
Cloud-A’s Channel Manager, Geoff Sullivan recently did a webinar
CloudBerry Explorer for OpenStack is built on OpenStack Swift technology, which means that users can use it with Cloud-A’s Bulk Storage ($0.075 per GB per month). You will need to create at least one Bulk Storage container by navigating to the storage tab in the Cloud-A dashboard and selecting “New Container.” Appropriately name your container and you are ready to download Cloudberry Explorer.
Tip: To keep your cloud-synced files organized, we recommend creating multiple Bulk Storage containers and treat them as if they were a folder directory on your local system.
Navigate to http://www.cloudberrylab.com/download-thanks.aspx?prod=cbosfree and download CloudBerry Explorer for OpenStack Storage.
Simply follow the steps to completed the installation wizard program.
Once CloudBerry Explorer has launched you will notice that the left side of the screen represents your local systems folder directory and the right represents cloud storage. On the cloud storage side click the source drop down menu and select:
<New Storage Account>
Then enter your specific credentials as follows:
Now Select “Test Connection” to ensure that the system has accepted your credentials.
If Test Connection fails, ensure that you have entered your credentials correctly. If you have entered your credentials correctly but are still receiving a “Connection Failed” error message, ensure that you have the correct ports open for Bulk Storage. Those ports are: 80, 443, 8443 and 8444.
If your credentials were entered correctly, the Bulk Storage container you created in the first step will appear in the file directory on the right side of the screen. To test the connection, select a test file from your local system, and select “Copy.” A transfer status message will appear briefly at the bottom of the screen and the file will copy from the left side of the screen and appear in your cloud storage container on the right.
To prove this concept, log into your Cloud-A dashboard and navigate to your new Bulk Storage container. You should see your test file.
CloudBerry Explorer is a great way to manually sync files to Cloud-A, and a great introduction into hybrid cloud solutions. Check out some of CloudBerry Lab’s other products for more advanced features like scheduled backups and encrypting files.
Meanwhile, in a not-so-different industry, application developers have been leveraging “new” cloud technology which allows for self serving, on-demand infrastructure, requires no upfront equipment cost, allows you to pay for what you use, and with no buyer-lock in. This is known as the public cloud – powered by Openstack.
Many of the benefits of an Openstack public cloud that software development companies have been enjoying since the inception of the technology can also be enjoyed by a managed service provider. The disconnect? Many of the features of an Openstack public cloud that create these benefits are features that historically, have only mattered to a developer. The reality is, these features can be extremely valuable to an MSP as well.
OpenStack is an opensource project and a community of thousands of developers who contribute to the ongoing growth of the product. While opensource isn’t typically a concept discussed in the IT channel, the concept ensures rapid and ongoing innovation, which in turn allows a MSP to introduce new functionality and features to their own clients.
In a highly competitive industry like the IT channel, differentiating your service from your competitors can make the difference between being competitive and being the leader. Offering your client base innovative, leading edge products and services creates value for your clients and a competitive edge for your business.
APIs are what developers use to automate the process of connecting one application to another. Developers use APIs to link functionality of their products to existing products so that their end users don’t have to do it manually. Why would APIs matter to an MSP? Many of the manual, labour intensive processes MSPs would typically perform to manage their client’s infrastructure can be automated with an API driven public cloud.
More and more public cloud friendly applications are coming to market that integrate directly with public clouds through their APIs. Take Cloudberry Lab (www.cloudberrylab.com) as one example. Cloudberry makes products that synchronize and/or backup local systems to Openstack public clouds, among others. This functionality is driven by APIs.
API driven public clouds, and the abundance of available third party applications are enabling MSPs to expand their product and service portfolio, automate laborious processes and create more value for their clients.
Developers enjoy the benefit of the bill-by-the-minute pricing model of the public cloud for building products, test environments, and other workflows where instances aren’t required to be powered on 24/7.
Utility billing sets MSPs free from hardware staging and allows them to avoid using expensive, production equipment for proof of concept testing and client demonstrations. The economics of the utility model also prevent MSPs from incurring long term colocation or dedicated server contracts, allowing them to add infrastructure as they add clients, and scale back infrastructure when it isn’t needed.
Cloud technology has changed, and it has created an excellent opportunity for MSPs to revolutionize their service delivery model with modern technology, streamlined process, reduced service labour costs, and more attractive economics. Developers have been realizing these benefits for years, and the time is now for MSPs to do the same to gain a competitive edge in their markets.