As a sponsor of the event, we welcomed the opportunity to learn how Layer products can help channel partners, both now and in the future.
Here are some snaps from the week.
This post was written after a discussion with a co-worker on the most suitable (yet adaptable) model for large-scale enterprise product development from architectural, team & technical perspectives.
Firstly, let’s think about what we are trying to achieve when forming a strategic model for a new product or service:
And from a strategic perspective, how to achieve that:
The rise in adoption of continuous integration & delivery over recent years has provided software companies a competitive advantage by being able to build pipelines that allow them to iterate fast and deliver value to customers by releasing live to to production in minutes, not days, so absolutely deployment in strategy. In fact, DevOps everywhere!
2008: You release every two weeks? How agile!
2019: We need that feature live in about 15 minutes. Kthxbye!
Of course, it depends on what you’re building and your target audience, but if you are creating a commercial application and you have competitors and/or customers with high expectations (who doesn’t?), having the ability to adapt, change & innovate is key to the success of your product. Although this has pretty much always been the case, improved tooling and technologies mean your competitors will gain advantages if you can’t keep pace with change.
So that’s all well and good in theory, and you already know that DevOps is an important part of any software team, but isn’t that going to be quite hard to do at scale, and with the rapidly changing pace of technology?
Yes, that’s where we start to look at the piece between software and DevOps: stack abstraction through containerisation!
But let’s not go straight there…
When it comes to specific software development techniques, the industry moves so fast, that while a seasoned professional should be able to speak confidently about most technologies, even the most experienced developer or team lead can’t profess to know it all.
This has led to a shift in development approach from single-platform/framework, dictated by the technical lead, through to polyglot architecture (still defined by the technical lead, but slightly less of a dictatorship!)
Here’s an anecdotal timeline of architecture trends in commercial software development:
2007: Proprietary all the way (letting developers in)
2010: A healthy mix of propitiatory & open source with API
2012: API first design
2016: API driven micro-services, improved CI/CD
2019: As above, but containerised & pro-polyglot!
So building a solid team is underpinned by platform & DevOps, even if there are just a few of us?
If you have the resources,build our your process with maximum visibility in mind so you can get out of your team’s way and let them do their jobs, setting clear and transparent expectations and deliverables. If you don’t have the resources, do exactly the same! Build out your model as if you do, if you can commit the time upfront.
There are plenty of tools available to help a startup match the tech stack & pipeline of a fortune 500 company. It’s an even playing field.
So, to the team formation part…
As Patrick Lencioni says in “Five Dysfunctions of a Team“:
Not finance, not strategy, not technology, it’s teamwork that remains the ultimate competitive advantage.
A technical leader should understand the various different approaches to building a scaleable & maintainable development model, from both a technical and team perspective, and select the programming model and tenancy model is a crucial part of building a team that gels.
The rest, DevOps, feature planning, etc., can then fall into place. I’m not going to cover that in this article!
So, here are three approaches for structuring your teams at the highest level:
Letting your team develop the solutions your business needs using the technologies they are best at. This is a scary solution for leaders, both technical and non-technical, due to the fact that that it might not always be easy to maintain the skillsets required to maintain your products.
Upsides: Your team is free to use the skills they’re most comfortable with. Your team will probably be happier, programming with the tech they love, and you’ll get a better product.
Downsides: Skill fragmentation, hard to manage, DevOps role is crucial to keep some control over project, so might not suit everyone.
This model involves selecting a core platform which will accommodate most of your needs, but doesn’t restrict your business to a technology per application within your business. With Docker support in Windows Server 2016, this approach is becoming increasingly popular in corporations, as well as small teams.
This way, your team are slightly more free (than using a specific language or stack) to create on their own terms, but having a defined platform at the base provides a little more structure and organisation.
It’s almost the opposite to the free-for-all approach described above and makes things easier to manage under a single platform.
Upsides: Be less fussy about the talent you hire, easier to maintain with common base
Downsides: Might not suit smaller teams
Closed (or vendor specific) software gets a bad name in 2018, but if done correctly and opened up to developers, it can be the right choice in many situations, especially when building a platform.
Upsides: Go deep with industry specific features, entire team on same stack, easier management, better stability if everyone in the team can support it
Downsides: Vendor locking, technology locking, harder to change if entire platform is based on one technology.
Overall, my core values remain consistent throughout the years:
Note that my thoughts below don’t cover the product side, which is roughly covered here.
Today I spent the morning meeting students at CodeClan in Glasgow. The team is helping nurture new talent in the Scottish software scene via an intense 16-week course covering everything from object-oriented principles to designing and developing apps in a variety of languages.
Taught by industry professionals, the candidates were all equipped with not only the technical principles, but taught that software development is an increasingly social career choice, with the best results coming from interaction & understanding over “technical-first” development.
What’s more, many of the courses are SQA approved, meaning they’re able to award recognised qualifications. If you’re interested in getting started in software development or are an employer looking for some new recruits, check them out at http://codeclan.com
The route to DevOps is a cultural shift which is integral to the success of any software business.
You might not do it all right now, and that’s fine.
You might do some parts well, and some parts not so well. That’s fine too.
Extending DevOps is a journey, with the end goal being connecting the same principles & practices you do with your development teams to the rest of your business, ultimately creating a scalable workflow, manageable team cadence and by becoming more responsive and agile than before.
Let’s start by looking at what DevOps might look like to a typical developer:
You’re probably asking how we roll the above out to non-technical teams, however, the principles in each of the practices above can be implemented around existing frameworks & systems in use by project teams and can augment support processes and even help boost your sales function.
All too often, development, product, and operations teams work in silos, with too little discussion around the important stuff;
DevOps is about inclusion, and we must fight spell check’s urge to put a space in between the two words comprising the portmanteau!
REMOVE THE SPACE.
So we know roughly what DevOps looks like from a software team, but how do we implement it throughout the company?
I firmly believe it comes from the top, and by introducing better communication channels between historically disconnected teams.
Ops, Meet Dev
The main benefit of getting your operations team on board with DevOps is cohesion. It’s probably fair to say that your operations team doesn’t want to be looking at JIRA boards all day, just as your development team doesn’t need to know each and every thought. However, agreeing on a common toolset and having buy-in to ensure this is used correctly is a great way to ensure that both teams work together to ensure the delivery of relevant and high-quality software.
The result of doing this is that it breaks down the traditional barriers and ‘God complex’ which sometimes breeds in development teams by bringing everyone, from the product team to the support people into the product design, development and QA process.
Dev, Meet Ops
So you’ve got your systems (close to) perfect, what next?
Speedy code shipments and quick feedback loops are what most developers working in a team want: their work gets from their workstations to users’ screens much faster and continuous delivery enables faster iteration and product improvement.
If you’re just getting around to implementing DevOps, why not set up a few key metrics to check if it’s working for you as you transition:
Start small with the cultural shift.
Implement tried and tested processes within your development team, and then look for buy-in from your operations team and repeat.
Then you’ll be one.
Strathclyde University‘s Centre for Lifelong Learning has an amazing workshop called FABLAB, which is home to loads of high-spec tools & equipment. Graham Murdoch runs daytime and evening classes here. I did one this spring and built a dog lamp, pictured below. You should check out the course details here and register for the next session!
My name is Warren Stroud and I am the Managing Director at Voice2Voice Ltd. We are a international business that have been in business since 2003. We concentrate on multi-site organisations, supplying them with their telecommunication infrastructure and services.
The reason why we selected The Layer was to move away from various other programmes like Microsoft Dynamics, which was running our CRM, various spreadsheets, which were running the back office side of things, and various subscription models that handled all of our quoting processes.
From an order management perspective we never really had something in place that could take the equipment quoted within a proposal and follow that right through to invoicing. The Layer addresses that perfectly with barcodes, scan readers and a simple process of taking an order and processing through from a customer services perspective.
The Layer captures every bit of information that is needed here at Voice2Voice. The dashboards give us a good idea of what’s happening within the organisation. Our sales dashboard can tell us prospects, to quotes that have gone out, and even margins that can be made on the various deals that are out there. Help desk dashboard gives management information on cases that need addressing urgently [inaudible 00:01:33] being breached and general customer service.
My recommendation for someone who’s looking to change their CRM package, especially in the telecommunications industry, is to be quite wary. There are a lot of products out there, we’re a prime example of a company who used many of the products that are out there. When we found The Layer, we now know that it encompasses everything that an IT support or telecoms company requires in order to run their business.
I would definitely recommend The Layer to anyone who’s interested in it. It has brought this business to a new level with regards to profitability, efficiency and customer service.
I’m Mat Whyman, head of marketing, and key account manager for Tru Solutions. Tru Solutions are a complete business communications provider. We offer mobile, fixed line data, and managed services. We originally started looking for a quoting tool, and looked at two or three different processes. We also were interested in the CRM. When we saw what The Layer did, it was a no-brainer. The Layer took us through every process in the business we were looking to improve.
So our key business issues were finding an easy to use quoting tool for our sales guys, as opposed to producing a commercial report or template separate to that, and having no control. I think we wanted a system where the quoting was easy. So The Layer helps us solve our issues by condensing multi-supplier price books, products, and offerings into one platform.
The sales order process has also given us the ability to be able to track where we’re at in the process of completing the sales order. We’re not having to duplicate anything for capturing, for data capture. That converts through from the sales order process, which converts through from the quote. So there’s no room for error.
So from a management perspective, The Layer has given us a higher view of everything, from telesales operation, to booking appointments, where we’re winning, and where we’re not winning. Where we need to change, through to what sales activity we’ve got going on. Who is busy? Who is not?
The main benefits that we’ve seen since using The Layer are move effective on renewals, and at the point where we renew it ahead of time, as opposed to after events. That daily interaction with our customer base is invaluable. Also, profitability, we’ve actually increase profitability since using The Layer. 2015, we have 95% feedback from our customer base on the cases that we manage, which we thought was excellent. 2016, it was up to 97% positive feedback, and 2017 to date, is currently at 98% feedback. So it is helping us progress and to learn from our mistakes.
From a support and training perspective, The Layer came down and spent quite a bit of time with our staff, and took them through the modules that they needed training on, introduced them to the system fully, and then have since supported us impeccably since we went live. So I’d definitely recommend The Layer to any commerce business. It’s given us a streamlined process. It’s given us a condensed view of multi-suppliers, multi-clients, all in one place, and it’s given us control. It’s empowered Tru Solutions.
Thanks to my awesome friends & family for helping me raise £1,775 for the British Lung Foundation.
Ensuring your log files are in good shape when using SQL Server with AlwaysOn Availability Groups is essential and should be an integral part of your database deployment & management strategy. Since AlwaysOn requires full recovery model to be enabled prior to configuration, your logs must be backed up regularly in addition to the database itself.
If you’re reading this, it’s more than likely you’re trying to find an easy way to clear down your growing log files. I’d recommend taking a little time to think about why it’s happening in the first place before you do anything else. Perhaps your logs aren’t backing up properly, your preferred backup replica is configured incorrectly or one of your secondary replicas is in error or playing up, Whatever the reason, diagnose it before going any further using the steps below.
The best place to start is by examining the state of your transaction log files in order to determine the reason that your logs are filling up and space isn’t being cleared. You can do this by issuing dbcc loginfo against the database with issues then cross reference the reason ID(s) against Microsoft’s Factors That Can Delay Log Truncation list (from sys.databases).
So you’re not using HADR?
If you haven’t implemented a high availability solution such as AlwaysOn or database mirroring, a temporary fix (if your RPO allows) is to change your data recovery model to Simple in order to avoid backing up transaction logs at all. This isn’t recommended for any production environment where data loss is a concern. Again, do not attempt to change this if your database is part of an AlwaysOn Availability Group.
And if you are?
OK, so we’ve already established that why our logs aren’t backing up by running dbcc loginfo. Let’s run the following in SSMS against all the databases causing you problems so we know what we’re working with prior to attempting to resolve the issue
If your logs are massive and growing *and* you’re taking regular backups, it’s worth checking that the SQL Server instance you’re taking backups on is set as the preferred backup replica in SQL Server. An incorrect setting in here can often delay the truncation of transaction logs.
Let’s free up some space
Ok, now we know which databases (and logs) are causing the problems, we can start to try and shrink them. If the results of your dbcc loginfo show that a replication issue is a potential problem, check the health of your availability group via the dashboard to ensure your replicas are in good shape. If not, you could remove the offending servers from the group until you’ve resolved the issue.
Next, take a backup of your log files. If space isn’t a concern, back these up to a physical drive. If you’re having issues with space (which is more than likely if you’re reading this), dump it to NULL. Please do this at your own risk as NUL is a special place in the file system. It’s the nul device, the outside bin or black hole of the file system.
BACKUP LOG [yourDatabase] TO DISK=‘NUL:’
Next, if required, let’s start to shrink your files. Again, run these at your own risk and ensure you have a full backup in place beforehand:
DBCC SHRINKFILE (yourDatabase_Log, EMPTYFILE);
Finally, get your backups back to normal and then go and explore what was *actually* causing your issue in the first place.
A good place to start is to ensure your backup solution is taking regular full backups, as well as frequent differentials & transaction logs.
Week #2 in the Kilmarnock Standard – Must have been a quiet news week!