CAMBRIDGE, Mass. – Part of the Boston area’s high-tech community came together at MIT on Tuesday for the ReDev B0st0n Conference, sponsored by the Mass Technology Leadership Council. MassTLC also puts on big events like the Boston TechJam, and is the largest and most influential technology association in New England – yes, even more so than local chapters of the Institute of Electrical and Electronics Engineers (IEEE), of which I used to be a member.
The one-day conference consisted of several keynote speakers and breakout sessions, the latter covering a wide range of subjects. Simply put, there was something for everyone in the industry here, which is wide-ranging even though there are some clear patterns emerging. One theme that clearly showed up in sessions here is, not surprisingly, the importance of data – and a lot of it. “Big Data” is one of the big technical buzzwords of the day.
Aside from the substance, which we’ll get to, the vibe was overwhelmingly positive. There were plenty of opportunities for networking in between all of the keynotes and sessions, in addition to a networking reception and career fair afterwards. There were many lively conversations had in the halls.
The morning began with a keynote from Stephen Fink of IBM, and he led into his talk about “The Serverless Revolution” with the scenario of an unhappy developer named Dave. He was so excited about this new job he was starting, thinking he would get to work on challenging, innovative projects. It all seemed so wonderful. Then reality sets in: Dave finds himself dealing with things like deployment, fault tolerance, resource management, and other minutiae that is necessary but certainly not fun. He even talks to his manager about it, and his manager basically says, “Dave… that’s life.”
The packed room laughed, perhaps in part because we can all relate. We know a job is not 100 percent fun, as there is always grunt work. Even in my side business, there are unenjoyable tasks and even times where it becomes a grind. That is okay, until it becomes the bulk of the work.
The idea behind serverless, on which IBM has an active project called BlueMix, is making this fun again. It lets the Daves of the world write functions and event-driven programming, you can scale instantly, and users pay only for what they use. It places more of the overall responsibility on to the platform and less on the developers who use the platform.
This opening talk was on a subject outside my area of expertise, and at times I can get lost in terminology in talks like this. But Fink’s presentation kept my attention the entire time and gave me something to explore a little further.
For the first breakout session, I went to Five Keys to Building AppSec into DevOps by Chris Wysopal of Veracode (which has been acquired by CA). Wysopal even likes to call this DevSecOps to cover all the bases.
Most of us know that security is a major issue in many respects nowadays, but even with that, it is still a bit sobering to see some of what research on the subject turns up. A Veracode security report showed that 35 percent of programs in production have a hard-coded password somewhere in the code, 39 percent use risky or broken cryptographic algorithms, another 28 percent are vulnerable to redirect attacks, and 16 percent mix trusted and untrusted data. Perhaps more shocking is that even some health care applications are in the second category, although some of that likely comes from a HIPAA regulation stating that data must be encrypted.
The number that should startle a lot of managers is that 63 percent of internally developed applications fail OWASP testing. (OWASP is an online community that produces many things, including a testing guide that is used as a “best practice.”
The big message in the talk is that security cannot be patched in later in a project; it must be designed in all along and, more importantly, tested early on. Developers and managers should think about what will pass through the continuous integration and continuous delivery (CI/CD) pipeline on the path to eventual delivery. The sooner issues are found, the less they will cost, and with security, those costs can be a lot bigger than with more garden-variety defects.
The next breakout session I attended was an introduction to graph databases in .NET by Jennifer Parker of HealthcareSource. There has been one dominant database type for a long time, the relational database (RDB). Object databases came around a couple of decades ago, and some theorized they were better and would take over, but that never came close to happening, a subject I brought up in talking with Jennifer and a couple of others after the talk. A graph DB, on the other hand, may have more potential.
A graph database is represented by nodes and relationships. It combines qualities of a graph data structure, commonly taught in computer science and engineering, with a database. The structure semantically represent objects and relationships, the latter of which are first-class citizens with properties of their own. Relationships are the key – relational databases don’t really convey the relationships as clearly, which leads to immense SQL code as opposed to the query code needed with a graph DB.
Parker also showed how a graph DB can show route traversal more clearly than a relational database by showing them side by side, then using an example of finding a path from one node to another. Later, she gave an example of trying to find friends of friends with a particular medical condition, showing the SQL needed to produce it – many lines of complex code that had me happy we did not have a quiz in five minutes – and the Cypher code for a graph database (Neo4j, which HealthcareSource uses) instead, which was just a couple of lines of immensely simpler code.
There are some use cases that can make a lot of sense, such as social networks, recommendations engines, course work or experience needed for a degree or certification, and even network path finding.
With those sessions in the books, it was off to lunch and the first of two consecutive keynotes. At first, the lunch scene was a bit harried, as the room was packed without a seat to be had, and for a moment there was not a lunch for everyone. The latter was quickly remedied, and Jim Cuff and Teodora Stoian from Amazon Alexa delivered the first keynote.
When you’re in a business that has a particular day or two where significantly more activity than usual happens, it is important to plan ahead as much as possible, and this means not just having something down on paper. For Amazon, who has to plan for big days like Black Friday, Cyber Monday, Prime Day and others, they engage in this kind of planning on a big scale and well in advance.
With the Alexa business in particular, they have what are called “Alexa Game Days” to prep for such events. They do extensive load testing, monitoring, calibrate alarms and audits, test processes and do the equivalent of store walks, among other things, all to simulate one of those days. Other retail stores, particularly ones that are either entirely physical locations or have many more than Amazon does, have similar challenges, but they are not alone.
It’s not hard to imagine how this can apply to many businesses. For example, a business that runs conferences or similar events must plan for what could possibly happen on the day(s) of those events, possibly with simulated runs.
That takes us through about half of the conference. More on the afternoon keynotes and breakout sessions will be coming up a little later.