Posts Tagged 'Messaging'

May 11, 2016

Adventures in Bluemix: Migrating to MQ Light

One of my pet projects at SoftLayer is looking at a small collection of fancy scripts that scan through all registered Internet domain names to see how many of them are hosted on SoftLayer’s infrastructure. There are a lot of fun little challenges involved, but one of the biggest challenges is managing the distribution of work so that this scan doesn’t take all year. Queuing services are great for task distribution, and for my initial implementation I decided to give running a RabbitMQ instance a try, since at the time it was the only queuing service I was familiar with. Overall, it took me about a week and one beefy server to go from “I need a queue,” to “I have a queue that is actually doing what I need it to.”

While what I had set up worked, looking back, there is a lot about RabbitMQ that I didn’t really have the time to figure out properly. Around the time I finished the first run of this project, Bluemix announced that its MQLight service would allow connections from non-Bluemix resources. So when I got some free time, I decided to move the project to a Bluemix-hosted MQ Light queue, and take some notes on how the migration went.

Project overview

To better understand how much work was involved, let me quickly explain how the whole “scanning through every registered domain for SoftLayer hosted domains” thing works.

There are three main moving parts in the project:

  1. The Parser, which is responsible for reading through zone files (which are obtained from the various registrars), filtering out duplicates, and putting nicely formatted domains into a queue.
  2. The Resolver, which is responsible from taking the nicely formatted domains from queue #1, looking up the domain’s IP address, and putting the result into queue #2.
  3. The Checker, which takes the domains from queue #2, checks to see if the domains’ IPs belong to SoftLayer or not, and saves the result in a database.

Each queue entry is a package of about 500 domains, which is roughly 200Kb of text data consisting of the domain and some meta-data that I used to see how well everything was performing. There are around 160 million domains I need to review, and resolving a single domain can take anywhere from .001 seconds to four seconds, so being able to push domains quickly through queues is very important.

Things to be aware of

Going into this migration, I made a lot of assumptions about how things worked that caused me grief. So if you are in a similar situation, here is what I wish someone had told me.

AMQP 1.0: MQLight implements the AMQP 1.0 protocol, which is great, because it is the newest and greatest. As everyone knows, newer is usually better. The problem is that my application was using the python-pika library to connect to RabbitMQ, both of which implement AMQP 0.9, which isn’t fully compatible with AMQP 1.0. The Python library I was using gave me a version error when trying to connect to MQ Light. This required a bit of refactoring of my code in order to get everything working properly. The core ideas are the same, but some of the specific API calls are slightly different.

Persistence: Messages sent to a MQ Light queue without active subscribers will be lost, which took me a while to figure out. The UI indicates when this happens, so this is likely just a problem of me not reading the documentation properly and assuming MQ Light worked like RabbitMQ.



Messages sent to a MQLight queue without active subscribers will be lost.

Threads: The python-mqlight library uses threads fairly heavily, which is great for performance, but it makes programming a little more thought intensive. Make sure you wait for the connection to initialize before sending any messages, and make sure all your messages have been sent in before exiting.

Apache Proton: MQ Light is built on the Apache Qpid Proton project, and the Python library python-mqlight also uses this.

Setting up MQ Light

Aside from those small issues I mentioned, MQ Light was really easy to set up and start using, especially when compared to running my own RabbitMQ instance.



MQLight was really easy to set up and start using, especially when compared to running my own RabbitMQ instance.

  1. Set up the MQ Light Service in Bluemix.
  2. Install the python-mqlight library (or whatever library supports your language of choice). There are a variety of MQ Light Libraries.
  3. Try the send/receive examples.
  4. Write some code.
  5. Watch the messages come in, and profit.

That’s all there is to it. As a developer, the ease with which I can set up services to try is one of the best things about Bluemix, with MQ Light making a great addition to its portfolio of services.

Some real numbers

After I re-factored my code to be able to use either the pika or python-mqlight libraries interchangeably, I ran a sample set of data through each library to see what impact they had on overall performance, and I was pleasantly surprised to see the results.

Doing a full run-through of all domains would take about seven hours, so I ran this test with only 10,364 domains. Below are the running times for each section, in seconds.

Local RabbitMQ

This server was running on a 4 core, 49G Ram VSI.

Parser: 0.054s

Resolver: 90.485s

Checker: 0.0027s

Bluemix MQLight

Parser: 1.593s

Resolver: 86.756s

Checker: 6.766s

Since I am using the free, shared tier of MQ Light, I was honestly expecting much worse results. Having only a few seconds increase in runtime was a really big win for MQ Light.

Overall, I was very pleased working with MQ Light, and I highly suggest it as a starting place for anyone wanting to check out queuing services. It was easy to set up, free to try out, and pretty simple once I started to understand the basics.

-Chris

Categories: 
June 5, 2012

New SoftLayer.com Design: Build the Future

If you've been reading the SoftLayer Blog via an RSS feed or if you find yourself navigating directly to the portal to manage your SoftLayer account, you might not have noticed that the our main website has been updated again — and in dramatic fashion. Last fall we gave the site a slight refresh ... This time, we did a total rework.

We took the site in a new visual direction, with graphics and messaging to complement our mantra of customers using our platform to create their vision — to build the future.

SoftLayer Homepage

The new look — referred to as "SoftLayer at Night" by my fellow SoftLayer developer friend, Seth Thornberry — was designed to reflect our core identity, and it retires the faithful red, white and grey theme that has served us well for more than three years. The new style has received rave reviews from customers, partners and employees, and even if there has been some criticism — everyone has an opinion nowadays — we can generally chalk it up to people simply not liking change.

Highlights of the Redesign:

  • A dramatic new home page design, including visually rich "hero images" (where you see "The InnerLayer" heading if you're reading this on the SoftLayer Blog)
    SoftLayer Homepage Hero Image
  • Expanded main navigation menus at the top of each page
    SoftLayer Homepage Top Nav
  • A new lower-order navigation system on the left of all content pages
  • SoftLayer Homepage Side Nav

  • [For typographically inclined] The new design also leverages web fonts functionality to incorporate "Benton Sans," the corporate font used in print, interactive and other marketing communications.
    SoftLayer Homepage Side Nav

The new design was executed in-house, and our workflow was pretty traditional ... We like to roll up our sleeves. Page templates were created as PSD files and then hand-coded in HTML, PHP, JavaScript and CSS on top of the same framework we use for the SoftLayer Customer Portal.

During the development process, we used our new GIT code repository to facilitate the merging of all of our code onto our staging server. Since it was our first time to use GIT in a major way, there was a bit of a learning curve. The first few merges had to be reworked after finding a few errors in commit messages, but after we got a little practice, the subsequent merges went off without a hitch. The final staging merge was a breeze, and given the struggles we've had with SVN in past projects, this was a huge relief.

When it came time for the design's official launch, we ran into a hiccup related to our automatic regression testing system and problems with cached CSS files, but these issues were quickly resolved, and the new-look SoftLayer.com went live.

It took a lot of hard work from (and a lot of caffeine for) a number of people to get the new site out the door, so I'd like to make sure credit goes where it's due. Our lead designer Carlos ("Los") Ruiz did a majority of the design work, and the implementation of that design fell to Dennis Dolliver (Website Developer), Charles King (SEO Manager) and me. I should also send a shout-out to the entire marketing team who jumped in to help to proof content, test pages and keep everyone sane.

What do you think of the new design? Stay tuned for more website improvements and additions!

-Brad

May 9, 2012

Nexmo: Tech Partner Spotlight

This guest blog comes to us from Nexmo, a featured member of the SoftLayer Technology Partners Marketplace. Nexmo is the wholesale messaging API that lets you send and receive high volumes of SMS at a global level. In this video we talk to Nexmo CEO Tony Jamous about the benefits of Nexmo, how it came to be and the problem it solves for you.

Cutting out the Middleman with Nexmo

These days, optimizing mobile messaging deliverability comes at a price. Businesses must connect to multiple carriers, operate heavy infrastructure, and build their own data analytics. On top of that, many third-party SMS solutions require contracts, price negotiations and significant up-front costs.

Nexmo was created to eliminate the need for a business to connect to carriers or complex third party protocols through simple, powerful RESTful and SMPP APIs. Our scalable infrastructure allows you to send and receive SMS in high volumes to over 5 billion users around the world. This is a market need that hasn't been addressed, and we approached it with a few ideas in mind. If you were going to replicate the functionality of Nexmo on your own, these are the key areas you'd have to look at:

Direct to Carrier Model

With every hop, the quality of a connection has the potential to degrade, and cost inflates. Adding intermediaries in the chain also impact the granularity of collected data, such as delivery reports and reasons of failure. By reducing the number of hops to the final subscriber you'll see:

  • An improved delivery ratio and lower latency
  • Enhanced security
  • Fewer single points of failure
  • Reduced cost, less fat in the chain

With a closer position to the final carrier, a business can access more "Telco" data like phone status, whether it is ported to another network, or if it's roaming abroad. With that information, you can also make better routing decisions and ultimately see higher delivery ratios.

Get Your own SMS-Enabled Phone Numbers

We've seen in the last two years the emergence of "Over the Top" (OTT) messaging apps such as Google Voice and TextPlus. Those apps provide a virtual phone number to each user, and Nexmo behaves similarly by enabling apps to behave like a "super virtual carrier" without the need for heavy Telco infrastructure. North America is the most mature market with OTT players generating significant SMS traffic, and now these models are going abroad. We pinpointed a unique need in the value chain:

  • Source virtual phone numbers from global carriers
  • Build the business models that protect carriers' interests without eliminating the opportunity for innovative apps
  • Provide the elastic and scalable cloud infrastructure for high volume two-way transactions

Nexmo approached those needs with APIs that enabled app developers to search for available phone numbers, provision new numbers and cancel numbers they weren't using any more. It doesn't take days or weeks to launch in a new market ... Apps can launch in a new market in a matter of hours with minimal upfront investment!

Improve and Track Deliverability

Enterprises and developers have shifted the focus in the buying process. They are looking for more transparency and accountability, so tracking and monitoring hundreds, thousands or even millions of messages can be of utmost importance.

For every SMS sent, the Nexmo API provides a detailed report of delivery. We push this data into the cloud in real time, displayed in two ratios:

  • The Success Ratio: The percentage of message received by the phone. This ratio measures how well traffic is performing.
  • The DLR Ratio: The percentage of messages with a delivery receipt. This ratio tracks infrastructure and route performance.

Follow the Life of a Message from the Cloud

Most B2C services and resellers that send millions of SMS for things like alerts, phone verifications and access codes can get swarmed when it comes to user support. We know that's an intimidating prospect for any business looking to add SMS functionality to their app or platform, so we let our customers follow the life of a message from the cloud and gather more information about it. Some of the information we've found most helpful to track:

  • How fast was the message was delivered?
  • Was the phone available for receiving SMS?
  • Did the user enter the correct phone number?

Keeping an eye on these basic kinds of stats reduces the pain of supporting a large user base and enables your support staff to answer questions quickly because they have a good foundation of information.

Receive Outstanding Support

Building a customer centric culture is a sustainable competitive advantage. It is even more meaningful in a commoditized, price-driven industry like wholesale telecom. If you're going to approach the world of SMS messaging and deliverability, the need for outstanding support is even more urgent because, given the nature of SMS messaging, results are expected immediately.

When we started Nexmo, we knew that, and I'm proud to report that we constantly score over 95% in customer satisfaction, and we've noticed a few tricks that have helped us maintain that level of support:

  • Hire the right people: Empathy and service mindset are more important than technical skills
  • Provide self-help tools and open knowledge bases: Customers appreciate finding solutions by themselves
  • Measure help-desk performance and constantly improve: KPI includes first meaningful reply time, resolution time and satisfaction ratio.

We hope these tips can help you build on your existing support or give you a jumping-off point if you're just getting started.

There is so much more I could tell you about our experience in building Nexmo into the platform it is today, but it's a lot easier for you to just see for yourself. If you're interested in learning more about Nexmo, visit http://nexmo.com, sign up, and be ready to go live with us in a matter of minutes ... And to make it even easier, you can use the free credits we provide to give the platform a test drive.

If you've been intimidated by the daunting task of knocking on the doors of telcos and carriers to get easy-to-use and easy-to-track SMS functionality in your app, Nexmo can save you a lot of headaches.

-Tony Jamous, Nexmo

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
Subscribe to messaging