Saturday, June 30, 2018

Infrastructure and Technology Changes; Cloud Applications In 2018 and Beyond

Now that the dust has settled and inLeague is able to serve all of our customers at AYSO, we wanted to focus on what decisions we could make to keep our technology both sturdy where it needs to be (inLeague has 99.99% uptime since 2010) while retaining flexibility to adapt to new best developments and best practices in the cloud software world.

To that end, we are undertaking several major shifts in the second half of 2018:

  • Server hosting: Codero "Bare Metal" servers to DigitalOcean "droplets"
  • Server Operating System: Windows 2012 Server to Ubuntu Linux 18.04
  • Application Engine: Adobe Coldfusion to Lucee 

Welcome to inLeague.io

1) Changing our server infrastructure and provider. Since inLeague first "went pro" in 2005 with the addition of its second and third regions in New York, all of our services have been hosted at the company now known as Codero, headquartered across town from us in Austin, TX. We've been very satisfied with Codero, but the industry is moving away from the types of "bare metal" deployments (where we lease physical servers in their data centers) in which Codero specialized. An analogy often used when us geeks get together to talk about this sort of thing is "pets versus cattle":


Historically, our servers have been pets: they have names and regular checkups, and if something happens to them, we drop everything and rush to make them better. They don't (usually) leave us hairballs in the middle of the night, but they also aren't especially appreciative of the trouble we go to on their behalf. More importantly, growth is constrained because it often involves adopting an entirely new pet.

For the last few years, we've seen a sea change toward cattle -- functional but more (if not entirely) anonymous units that are interchangeable; when one gets sick, you still figure out what went wrong, but you get another to take its place right away to minimize downtime and ease maintenance and upgrades.

This being Texas, cattle are of course not interchangeable, and we're imagining that all of our cattle will be longhorns.

If the "cattle" in this analogy are the hardware we use for running our databases and application servers, the software equivalent -- writing our code in such a way that it makes no difference where it's running -- is called containerization, named for the shipping containers that represent a way of packaging software so that it is just as easy to deploy ten of something as it is to deploy one. We have been gradually adapting our software to this model over the last two years, and hope to complete the process by the end of 2018.

As software companies use fewer pets and more cattle, companies like our current host are partnering with larger, "infrastructure-as-a-service" providers like Amazon or Google to re-sell their services. Rather than purchase re-sold infrastructure, we're going right to the source with DigitalOcean and relocating our (now much more bovine) servers to their data centers in New York City. If you've been following inLeague for a long time, you know that we believe in the freedom to choose the best tool for the job; and while we use and depend on many Google and Amazon services in our applications, we didn't want to be locked into their ecosystems, and found DigitalOcean to be a very reputable, popular, and (best of all) affordable solution. To distinguish our updated products, we've secured a new domain name: inleague.io -- this will ultimately succeed most inleague.org sites, but both will co-exist for many years to come.

We'll be sorry to leave Codero behind, and we recommend anybody interested in an Amazon-centric reseller consider them as they've been a wonderful partner for us for a long time.

Current Status: In testing. We are building out our development and deployment pipelines on DigitalOcean. Our new Content Management System will host our first production sites on our new domain, inleague.io, and we will focus on our flagship applications in the Fall after the start of the Soccer season (for inLeague) and the school year (for inRoll).

Windows to Linux: You Can Invite Us to the Cool Parties, Now



2) As of the Summer of 2018, containerized deployments in production are almost always done on Linux. We expect this to change, as Windows Server 2016 updated and Server 2019 both emphasize container support, but for container-based applications today, Linux cattle are the best cattle. Since most of inLeague's technology stack is Java-based, and Java runs on any operating system, this has more of an impact on inLeague's DevOps (Development and Operations) practices than our software. We've been "Windows People" on the server side for fifteen years, but before that, we started out on Linux, so we're coming full circle and restoring our geek street cred with Ubuntu Linux. This change was made possible, ironically enough, by Microsoft's embrace of Linux for their database platform that inLeague has used from the beginning -- SQL Server. Without Microsoft's willingness to let their customers choose the best tools for the job, we wouldn't have been able to abandon Windows Server -- so we part on good terms, and we expect to look at Windows again in the future as we don't expect them to cede the battle for containerization to Linux.

A nice perk with this change in strategy is that we are able to take the budget we were spending on Windows Server licensing and invest it into hardware. This lets us streamline our operations to make every dollar our clients give us to support their business or their league as efficient as possible.

Sayonara, Adobe Coldfusion



3) Changing our application development engine from Adobe's proprietary Coldfusion Markup Language (CFML) to Lucee, the open-source CFML alternative.

While the inLeague code base receives hundreds of updates every year, there is still some first-generation code from the original inLeague application in 2003. This makes our investment in Coldfusion long-lived, but that's not a reason to keep doing something; we can re-write code, but we've always been very careful to avoid technology fads that attract a lot of attention and then fizzle out after a couple of years. For some time now, Coldfusion hasn't been a popular choice for new applications, and a few years back we considered dropping it. Adobe's handling of the product seemed focused on providing support to government and enterprise clients rather than in developing the language or the technology. Fortunately for the CFML world, two things happened around the same time that rescued the language and the development community from the abyss of irrelevance: Lucee became a mature and mainstream product, and Ortus Solutions (makers of the estimable Coldbox, Commandbox, and Forgebox products, among others) took a leading role in the CF community with investments in their own open source platforms, conferences, and generally solving the kinds of problems that the community needed solving -- especially since Adobe didn't seem especially interested in doing so themselves.

The first post on this blog announced our original intention to do this back in 2015, and for some of our software, we got about 95% of the way there. For most everything we do, Lucee was faster and better. Unfortunately, for the other 5%, Lucee just didn't work -- not because it wasn't a good product, but because it's like a different dialect in any language: sometimes you have to say things differently to be understood, and re-writing that 5% would've been a huge investment in what was then still a fairly young product. So we "re-upped" our Adobe licenses for another few years.

Adobe is behind the curve with containerization and the future of the Coldfusion markup language is Lucee and Ortus. We've suspected this for some time, but now we're publicly betting the farm on it.

That's it for the Summer 2018 update -- we'll be back before the start of the season with some details on new features for inLeague and inLeague mobile!

Monday, July 25, 2016

Birth Certificate Processors



While we are waiting on AYSO National for our larger, Summer update, we've released a small utility to assist with birth certificate processing as well an access level to go with it.

Birth Certificate admin will have access (along with registrars and webmasters) to the birth certificate tool now available from the 'Players' menu. This tool will show all players on file who meet the following criteria:

- The 'birth certificate' field on their player/child record is 0
- They have an active registration within the last two years from today's date

Birth certificate admin can select one or more of these players to process, and the system will set this field to 1 and log the change -- the person who processed it, the date, and the time.

Note that birth certificate admin cannot access the player editor and they cannot "reverse" this process (i.e. they cannot set someone who already has a birth certificate recorded back to 0).

There is an option for an email confirmation that sends a short email to parent 1 and parent 2 (if present) indicating the receipt of the birth certificate. The context of that email may be edited by a webmaster from 'edit page content' on the birth certificate tool.

Note that the new access level (birth certificate administrator) will be query-able from the report center within the next day or so, but it is not currently in the Authorizations Center. The auth center is getting a re-write later this year and will be updated at that time along with some new functionality.

Monday, July 18, 2016

Pricing (2017 on) and inLeague Pro


Since inLeague first became inLeague in 2006, we have tried to keep our pricing as transparent as possible; and we have always operated on a per-player, per-season, per-module pricing model, most recently seen here:

inLeague Standard Rate Schedule circa June 2016. Prices last updated in 2009.
















We chose this model for a variety of reasons:
  • inLeague has always been a premium service targeted at leagues with greater than 500 players. Even so, it was important to us to provide entry points for leagues that were primarily interested in on-line registration solutions such that they wouldn't be paying an additional premium for scheduling services they didn't necessarily need.
  • The average price paid to register for youth sports in an inLeague program was around $100, but most leagues collected money for a variety of other activities (additional soccer programs, fundraising, off-season events); we felt that 5-7% of the registration fee was a good place for a service that kept the league running smoothly, but we didn't want to be taking percentages from "non-sports" events, even if they used inLeague to collect funds. We also didn't wanted our leagues to be the only recipient of their constituents' transactions, rather than having inLeague collect money on their behalf and then dispense to the league it every month.
  • We want to support league growth rather than penalizing it with higher fees.

In the ten years we've relied on this model, we've learned several things:
  • Just about every league uses all four "modules" (registration, team building, game scheduling, and referee scheduling); occasionally, a league would sign up for just one or two, but after a year would end up using all four.
  • Usage of inLeague has changed over the years with the rise of mobile devices and mobile apps. When we started out, our target audience was exclusively a league administrator or scheduler; parents would sign in once or twice a year to register their players and indicate volunteer roles. While we are still primarily a league-oriented product, much more of our development in 2016 is focused on "team-level" interactions between coaches and parents. A pricing model developed for a "desktop" web application doesn't allow for a lot of flexibility when our focus needs to be on products and platforms that didn't exist (for us, anyway) ten years ago.
  • The cost of participation has gone up. In the table below, "Registration Fee" refers to the initial payment made at the time of registration to participate in a soccer program. In many cases, particularly in the last few years with the expansion of "EXTRA" and other forms of competitive play, players submit additional payments over the course of the season. Avg. Participation Cost refers to the median amount paid over the course of a season, and Max Participation Cost refers to the most expensive individual program cost administered by a league. Of course, our leagues are not a representative sample of anything other than leagues that prefer to use inLeague.

Year Avg. Registration Fee Avg. Participation Cost Max Participation Cost Consumer Price Index (annual average)
2007 $89 $117 $1,200 207.3
2008 $96 $118 $1,200 215.3
2009 $97 $104 $1,000 214.54
2010 $100 $109 $1,175 218.06
2011 $110 $123 $1,550 224.94
2012 $112 $132 $1,700 229.59
2013 $118 $148 $1,820 232.96
2014 $131 $151 $1,700 236.74
2015 $141 $161 $2,650 237.02
2016 $151 $158 $2,600 238.78 (as of 6/16)


Takeaways from the above:
  1. Leagues either use inLeague or not; we're better off with discounted trials than with a pricing matrix when everyone prefers to use everything.
  2. The average, up-front participation cost has risen 51% since 2010; inLeague's prices were last set in 2009. 
  3. The Consumer Price Index shows inflation at 9.5-10.5% since 2010.
  4. Mobile development is a priority that the original model did not account for.
It is also the case that, as the cost of participation has gone up, so have the number (and dollar amount) of scholarships awarded by individual leagues.

Simplified Pricing for 2017 (subject to review)



We are retaining the league size scale model, but flattening the per-module portion. The updated model has the following goals:
  1. Long-term stability -- we do not want to revisit our base pricing model for the foreseeable future.
  2. Minimal changes for smaller leagues
  3. Our prices should inflate based on our own costs incurred and the Consumer Price Index. Our largest costs are software development (labor) followed at a distant second by hardware (server expenses), both of which have increased somewhat, but not tremendously, since 2010.
These changes will not impact the current (Fall 2016) season; they will impact any season that commences after 1/1/17.

inLeague Management Suite Subscription Pricing (per season), effective January 1, 2017

  • @500 Players: $6.75/player
  • @1000 Players: $5.40/player
  • @1500 Players: $5.15/player
  • @2000 Players: $4.70/player
  • @3500+ Players: $4.00/player

Enter inLeague Pro

We knew that we did not want to "fence off" functionality to which our leagues are accustomed behind an additional subscription fee. Because mobile development involves technology and skill sets on top of what we use to maintain our web applications, we focused on mobile development as the vehicle for adding additional value to our services. 

Before we could ask for a subscription fee, we had to learn how to build mobile applications and how to integrate them with our products. inLeague Mobile was first released in late 2014, and now supports several features:
  • Game schedules for players in the logged-in user's family
  • Game schedules for referees and coaches in the logged-in user's family (or league-wide)
  • Team Conversations - instant messages between coaches, team staff, and team parents
  • Center Refs and division heads may input game scores
inLeague Pro will be an optional subscription level for leagues beginning in 2017. The following details are subject to change, but the current plan is:
  • Game schedules and score input will continue to be freely accessible
  • Team Conversations and a new feature coming in the Fall of 2016 will become "Pro" features
  • inLeague Pro will cost $1 per player per year (not per season) regardless of league size
  • All leagues have been given automatic access to inLeague Pro through December 31st, 2016.

Going forward, only those services we consider both "premium" and "optional" will be part of inLeague Pro; the majority of our development will continue to be invested in the primary inLeague application and publicly-available inLeague Mobile.

Tuesday, July 5, 2016

Summer 2016: Welcome to the inLeague Development Blog!

Welcome to the inLeague Development Blog!


In the past, inLeague staff have sent seasonal emails to league administrators that summarize our development progress and our plans for the future. We will keep doing that, but the details will be posted and archived here, as well as linked from inleague.org and the inLeague application.

Summer 2016: eSignature, Concurrent Registration, and Lucee


We have three major initiatives underway for our Summer 2016 update: Player eSignature updates, concurrent multi-season registration, and a change in the back-end server software that runs the inLeague application suite.

eSignature 2.0 (Coming Soon) and Volunteer Registration Integration (Coming Next)

More eSignatures, please!

In 2014, inLeague worked with AYSO National Staff to integrate player registration with eAYSO. Since that time, the mechanism AYSO uses for eSignature has been revised, along with plans to include adult/volunteer registration and adult league player registration.

Previously, inLeague would record the name, internet address, and timestamp for all of the waivers preceding each registration, and then send that data to eAYSO. This system was largely invisible to the end user: it did not interrupt the registration process but occurred behind-the-scenes after registration was completed.

To improve the integrity and accessibility of the eSignature process, registrations will soon be directed just prior to the payment page to an eSignature page hosted by AYSO's eSignature vendor. This process is similar to Docusign: parents will be presented with a printable form and click through to 'sign' the form. The electronically signed form is archived and can be printed by the parent, a league administrator, or AYSO National Staff at any point in the future.

As of early July 2016, this system is in final testing with AYSO and we anticipate that it will be rolled out soon.

If all goes well, inLeague's next step this Fall will be to implement the same eAYSO and eSignature integration for volunteer registration -- no more separate, standalone eAYSO volunteer signup!

What Does eSignature Cost?

There are two elements to the cost of this system:
  • Annual and/or per-volume license and archive fees paid to the eSignature vendor
  • Development costs to integrate inLeague with eAYSO & and the eSignature vendor
AYSO National pays the former.

Development costs for this system are largely up-front; in theory, once the system is in operation, it should not require significant maintenance. 

inLeague will recover this cost through a per-player eAYSO Integration fee of sixty five cents. This fee was introduced in 2014; the original system was paid for by early 2016. The revision is significantly larger than the original system, but the fee will remain the same, and it will be phased out once the devleopment costs have been recovered and presuming there are only marginal new costs incurred.

Concurrent Player Registration for Multiple Seasons


Many leagues run travel, tournament, or development programs alongside their recreational programs. Registration timelines for these programs do not always line up with one another. Beginning with the forthcoming eSignature 2.0 rollout, inLeague will support concurrent registration for multiple seasons.

Coldfusion: Adobe to Lucee's Open Source Server Platform

Credit: Dilbert (http://dilbert.com/strip/2006-12-08)

inLeague's application software was developed in and deployed on Adobe's Coldfusion Markup Language. Every 2-4 years, we evaluate our server hardware and software so that we can best align our resources with our application development roadmap. There are four main pieces to our pipeline:
  • Our web and database servers, hosted for many years now by Codero (based here in Austin) with data centers in Phoenix, Dallas, and elsewhere;
  • Our database software (Microsoft SQL Server)
  • Our web application server software (Adobe Coldfusion)
  • Our software development framework that runs on the server software (currently a home-grown mix of solutions developed over the years by inLeague staff)
 As we prepare new servers for inLeague this fall, we also evaluated an open-source alternative to Adobe's Coldfusion platform called Lucee (formerly Railo).

Adobe's Coldfusion engine has served inLeague well for a long time, but Lucee's optimization, feature set, and community approach  are more in line with inLeague's mission and requirements. At the same time, we are evaluating a change in application development framework for our codebase from the home-grown solution we have been using to Framework One, one of a handful of widely-used Coldfusion development frameworks. Framework One (or fw/1)  updates and standardizes how we write our code and implement new features while eliminating repetitive tasks in collecting and processing data or displaying layouts.

All of these potential changes serve the same end, which is to make the most efficient use of resources that will enable us to continue rapid development and deployment of changes and new features to the inLeague application. They are some of the most significant back-end changes we have ever considered. To facilitate our evaluation and eventual transition to these new technologies, we anticipate establishing beta sites for many of our largest leagues so that league administrators and schedulers will be able to put inLeague to the test for the Fall 2016 season. These beta sites will be connected to our production database so that common tasks can be performed on our new systems while the current generation continues to run as a fallback solution until we 'flip the switch.'

We will be in touch with individual leagues in the coming weeks regarding all of these changes. Until then,  we're looking forward to a great Fall season!

All the best,
Samuel Knowlton
Founder & Chief Leagueologist