Technical and Product News and Insights from Rackspace
The traditional supply-chain management processes with on-site IT applications are rapidly moving to the modern supply-chain cloud infrastructure. This blog covers the characteristics and benefits of the modern supply chain management in detail.
Modern browsers have APIs called
find one or more elements matching a CSS selector. I’m assuming basic
familiarity with CSS selectors: how you select elements, classes and ids. If
you haven’t used them, the Mozilla Developer Network has an excellent
Running a successful developer workshop (aka tutorial) is really difficult. I’ve attended enough workshops that have gone poorly to know that for a fact. Participating in such a workshop can be very frustrating and a huge turn off for whatever technology is being presented. That translates directly into losing developer mindshare. I think we, as an industry, can do a better job of running developer workshops.
When we, at Rackspace were working on a data visualization dashboard which uses AngularJS framework, we needed to abort requests. Fortunately, AngularJS has amazing built in services of which $http and $resource helped us make these XHR(Ajax) requests much simpler. There are many resources to figure out which might be better for your use case. I’m going to describe how I implemented aborts in $resource and $http in an unified way which increased the performance and showed correct data.
Having spent my last 7 years concentrating mainly on Linux® and related technologies, I spent 3 days with PowerShell and here are the some observations and anecdotes. Why PowerShell? Curiosity for one and I wanted to learn it from a perspective of how to use it in configuration management tools like Chef. As an disclaimer, I’m not an expert in PowerShell and spending 3 days is just scraping the surface but I did learn quite a bit in that time. Also my prediction is that PowerShell will be real force (if not already) in Windows environments. It is a mindset change for several Windows administrators who have grown up on GUIs but that is about to change in the coming years. And if you are Linux administrator, you are likely to feel more comfortable interacting the PowerShell way. I definitely did.
If you’re a big PostgreSQL fan like I am, you may have heard of a tool called WAL-E. Originally developed by Heroku, WAL-E is a tool for efficiently sending PostgreSQL’s WAL (Write Ahead Log) to the cloud. In addition to Heroku, WAL-E is now used by many companies with large PostgreSQL deployments, including Instagram.
Let’s unpack what that means. If you’ve ever set up replication with PostgreSQL you’re probably familiar with the WAL. Essentially there are two parts to replication and backup in PostgreSQL, the “base backup” and the WAL. Base backups are a copy of your database files that can be taken while the database is running. You might create base backups every night, for example. The WAL is where PostgreSQL writes each and every transaction, as they happen. When you run normal replication, the leader will send its log file to the followers as it writes it.
Instead of just using a simple socket to communicate, WAL-E sends these base backups and WAL files across the internet with the help of a cloud object store, like Cloudfiles (or any OpenStack Swift deployment). This gives you the advantage that, in addition to just being replication, you have a durable backup of your database for disaster recovery. Further, you have effectively infinite read scalability from the archives, you can keep adding more followers without putting more stress on the leader.
With the help of WAL-E’s primary author, Daniel Farina, we recently added support for OpenStack Swift to it. It’s not yet in a final release, but if you’re interested in checking it out, read on!
One of the more pressing needs in the world of open source software is the need for decent documentation. That covers a lot of territory; from well-commented code (yeah… right) to API guides to the rare – some say mythical – user guide.
The hardest part about using new technology is knowing where to begin. Spending hours sifting through blog posts and documentation to set up a server environment is often enough to extinguish the excitement about a new framework or application. By the same token, it is frustrating to deploy hosting architecture when you are excited to see how your latest code will perform. And no one likes having to do the same things over and over to create consistent testing, staging and production environments.
Deploying your application to the cloud requires expertise in both system administration and development; often, people have expertise in some areas while having gaps in others. The Rackspace Deployments service was created so we could collect this information and expertise in machine and human readable format and use it to automatically and consistently deploy hosting configurations, frameworks and applications and alleviate some of this stress.
I am part of a team (along with Bruce Stringer and Jason Swindle) working on an internal application called Graffiti, which provides an easy way for front-line Rackers to record interactions with customers and provide valuable data with each interaction. It also creates a much simpler way for leads to be passed from the front line to the IB sales team here in SMB cloud.
We knew from the start that we wanted this to be an agile cloud application that utilizes all the things a cloud should be. We had some limitations which meant we had to home grow a few solutions. Since this is an internal application, we could not rely on third-party solutions for off loading workloads. We also had to be careful with our security practices, of course. We ended up going with a configuration that utilizes our internal nova solution for hosting in Cloud Servers. The downside to this is that we have no automated backups, no load balancers and no Cloud Files - much to my dismay.
Agile. Scrum. Extreme programming. RAD. Lean. These terms all represent a departure from the traditional Waterfall development process in favor of a more rapid, iterative approach to application development. For companies with large-scale web applications, there are significant benefits to the agile methodology, but it also presents significant challenges.
When every minute of downtime represents significant lost revenue and increased support costs, it stands to reason that application support should be just as agile as application development. Among other things, this means tearing down l ong-standing walls between teams, and getting all business units working together toward common goals.