The Offshore Development Centre (ODC) is designed to act as an extension of the client organization, seamlessly offering the flexible capacity to meet variable demand. As the ODC model has matured throughout the industry, it’s become clear that successful organizations not only need to deliver tailored solutions in a repeatable manner but also need to adapt to their clients’ culture and philosophy and have a set of good practices to build on and continuously lead clients in areas of improvement.

ODCs should create a virtuous circle of delivery, improvement, mutual gain, and trust. Furthermore, there is an innate belief and expectation that members of an ODC will be thinking and operating as if they were an official part of the client’s organization. This document highlights the characteristics of a “GOOD” ODC and also provides some guidelines and behaviors for how to achieve these characteristics.

This document covers the key activities and behaviors associated with operating as an ODC: acting and thinking as part of the client’s organization, driving continuous improvement and refinement of process and tasks to align with TwentyCi business strategies of doing more with less.  At the same time, our delivery methodology needs to fit the client’s culture, be applied consistently and have the same rigor and management of scope, timeliness, and quality as our project-based deliveries. This document is not a substitute for the quality management practices and templates also avoid going into details on any specific process.  The purpose is to complement the existing processes and practices, highlighting key steps and good behaviors.

 

Target / What good looks like

Guidelines / Behaviours

Agreed working processes are applied consistently throughout the ODC. The ODC maintains the correct balance of resource seniority. Succession plans are proactively maintained. Comprehensive reporting and KPIs are agreed and tracked to provide an objective measure of performance (whether requested by the client or not). There are clear roles and responsibilities identified with the client and among project team The correct balance of time, quality and cost are maintained. Productivity is managed. A log of discrete improvements to ODC working practices is established and maintained.

Think and act as the client, put yourself in their shoes. Avoid inconsistency, as it reduces the client’s confidence in company capability. Awareness of risks, issues, and KPIs to provide a client-orientated context for decisions.  Consider the client’s point of view. Seek to improve, offer ideas and suggestions. Clients are welcome for improvable positive ideas. ODC members are trusted to communicate and work effectively, directly with key customer stakeholders. The ODCs are enthusiastic and focused on delivery, and consider the long-term maintainability and performance of solutions they construct. The whole ODC operates in a professional manner, aware of clients’ perception at all times, especially where clients are physically present. If in doubt, the ODC team take ownership for the resolution of issues. Proactively raise risks and mitigation recommendations to the client.

 

Comment down below if you have any question or contact us via email for free consultation. Don’t forget to share & subscribe to our blog! See you in the next post!

                                                                                                                                                                                                                                                                        Hung Le                          

AWS – Amazon Web Services

Whether you’re striving for a new role as a DevOps engineer, or a startup looking to hire one, you’ll need to be in search of several specific AWS skills.

DevOps Pipeline

Jenkins isn’t the only build server, but it’s been around for a long time, so it’s popular. You can also do well with CircleCI or Travis or even Amazon’s own CodeBuild & CodePipeline.

You should also be comfortable with a configuration management system. Ansible is my personal favorite but obviously, there is lots of Puppet & Chef out there too. So let’s talk about the playbook you wrote, how it configures the server, installs packages, edits configs and restarts services.

Bonus points if you can talk about handling deployments with Autoscaling groups. Those dynamic environments can’t easily be captured in static host manifests, so talk about how you handle that.

Of course, you should also be good with Git, Bitbucket or Codecommit, discuss how you create a branch, what’s Gitflow and when/how do you tag a release.

Also be ready to discuss how a code checkin can trigger a post commit hook, which then can go and build your application, or new infra to test your code.

CloudFormation or Terraform

Terraform is MacOSX or iPhone to CloudFormation as Android or Windows. I’m partial to Terraform. Why? Well, it’s a more polished and nicer language to write in. CloudFormation is downright ugly. But hey, both of them can get the job done.

AWS Services

There are lots of them, but the core service is what you should really focus on in the interview. So here’re some key questions you should keep in mind:

CloudWatch for centralized logging, how does it integrate with ECS or EKS?

Route53, how do you create a zone? How do you do Geo Load Balancing? How does it integrate with CertificateManager? Can Terraform build these things?

EC2 is the basic computing service, what happens when an instance dies? Or when it boots? What is a user-data script? How do you use one? What’s an AMI? How do you build them?

What about virtual networking?  What is a VPC? Or a private subnet?  How do you deploy a NAT? What’s it for? How do security groups work?

What are S3 buckets? About infrequently accessed? How about glacier? What are lifecycle policies? How do you do Cross Region Replication? How do you setup CloudFront? What’s a distribution?

What types of load balancers are there? Classic & Application are the main ones. How do they differ? ALB is smarter, it can integrate with ECS for example. What settings should I be concerned with? What about health checks?

What is Autoscaling? How do I setup EC2 instances to do this? What’s an Autoscaling group? Target? How does it work with ECS? What about EKS?

DevOps isn’t about writing application code, but you’re surely going to do writing jobs. What language do you like? Python and shell scripting is a start. What about Lambda? Think about frameworks to deploy applications.

Databases

You should have excellent database skills even if you’re not the day-to-day DBA. Amazon RDS certainly makes administering a bit easier most of the time. But upgrading often requires downtime, and unfortunately, that’s wired into the service. Personally, I see mostly Postgresql, MySQL & Aurora. You should get comfortable tuning SQL queries and optimize, analyze your slow query log and provide an output.

Amazon’s analytics offering is getting stronger. The purpose-built Redshift is everywhere these days. It may use a PostgreSQL driver, but there’s a lot more under the hood. You also may want to look at Spectrum, which provides an external table type interface, to query data directly from S3.

Not on Redshift yet? Well, you can use Athena as an interface directly onto your data sitting in S3, it’s even quicker.

For larger data analysis or folks that have systems built around the technology, Hadoop deployments or EMR may be good to use as well.

 

What else do you think interviewers should question for a good DevOps?

Please leave a comment below or send an email, I’d love to know your opinions and discuss more of the subject.

                                                                                                                                   Nhat Nguyen