How Square enables rapid service creation

Square employs documentation-driven development within a service-oriented architecture to enable rapid deployment of new services.

Square is a fast-moving company that provides iOS and Android apps that enable merchants to accept credit-card payments right from their smartphones. It also is branching out into a service-oriented architecture to make it easy to create new services while enforcing documentation. 

A couple weeks back, at RubyConf 2012, Square's Chris Hunt described, in detail, the process by which Square's developers can quickly create new services that conform with the company's standards and processes. (See video, below.) In line with the conference at which he was presenting, Hunt provided a map of how he and his team built services based on Ruby, targeted to run in a mainly Java service-based environment. 

Four's API was functioning well as a payment service, but the company is rapidly expanding its range of capabilities and services, so the existing infrastructure was getting weighted down, Hunt relates. "We said, 'whoa, maybe we wanted to send people receipts now, and make it so that users can log in and see their history of payments, and sort them and search them and things like that. So we had 10 more controllers, and  a bunch more APIs in the same Rails app. And it starting getting really big, with a monolithic Rails app. Today, it has 183 controllers, 197 app models, and 657,000 lines of code."

As a result, features would take several days to add, and needed to be done at low-peak periods. The workaround, Hunt says, was to deploy "small services rather than adding features to the existing app that we still use." Square's teams already have access to pre-built frameworks that are structured with all essential elements of building a service, including monitoring and security. All services are deployed to Java Virtual Machines running across its infrastructure, supporting multiple languages, including Jruby and Python.

Square's service deployment process is documentation-driven, Hunt says. This is achieved through a mechanism called "fdoc," named in honor of Professor Farnesworth from the cartoon Futurama. fdoc requires documentation with all services. "fdoc looks at all the requests. If its not documented, then its going to break the build," he says.




Show Comments