Here are some great reasons to stop using email for team communication and instead switch to Slack
By default email messages are private – only available to the recipients. Slack messages are by default available to the whole team. Simply join the channel you’re interested in (or leave if not). How many times have you had to forward an email to someone who wasn’t on the original? or worse that other person never got to give their valuable contribution because they were never on the list?
Build a knowledge base – with email when someone leaves your company their account is deactivated and along with it all their sent emails. Imagine how useful this info could be if preserved and made searchable! Key decisions, how-tos and historical context can be available throughout the project and made available to all especially new comers.
Marketplace of apps – Slack has LOTS on fantastic integrations, like Git, Jenkins and JIRA which help to keep task communications flowing. Eg. see when a code review is required and openly discuss.
Self service – No need to request mailing lists from your email admin for topics or projects, simply create a channel and invite the relevant team members. E.g. Just developers working on project X
Multimedia – Call a video conference and screen share from within a shared channel without having to mess around with other conferencing apps. You can even give others control over your desktop (useful if it’s going to take too long to explain a technical task)
Sync and Async – Conversations are much closer to real-time than email, but still have the option of being asynchronous if you don’t want to be distracted.
Connection – Remote team mates feel more connected with Slack. You can see who’s online. You can see other work happening even if you’re not directly involved with the project or you can simply have a bit of banter with fellow employees easily without worrying about who should I CC in this email.
Strangers are friends – Other companies can be given access to a specific Slack channel and feel part of the team.
Don’t repeat yourself – No huge email chains with reply to all that require you to scroll through pages of crap to find the context on the conversation.
Within DevOps the terms Continuous Integration, Continuous Delivery and Continuous Deployment get thrown around a lot. Here is the simplest definition I could come up with to quickly explain each to a non techie like a project manager.
Continuous Integration
Running unit and other tests on every branch on every commit and merging to master every day
Continuous Delivery
As above but each commit CAN be pushed to production
This post shows step by step how to deploy your serverless Java AWS Lambas continuously to production. Moving from pull request, merge, build, deploy and finally test.
Overview
Project Setup
For our project we are going to assume a standard Maven Java project structure, with Cloudformation and build specification config in the root of the project.
Within the Maven pom.xml file, you must include the lambda core libraries.
The ChangeSet can then be executed and the changes automatically rolled out to production safely. Any problems encountered and an automatic rollback occurs.
Action Mode: Execute changeset
Stackname: <name of your created stack here>
Change set name: <change set name from previous step>
Outcome
Congratulations! you now have your Java AWS Lamba functions deploying to production using Continuous Deployment. AWS CodePipeline is easily configurable via the UI and can also be defined as code and stored in version control.
According to the 2015 Verizon Data Breach Investigations Report (DBIR). 98% of attacks are opportunistic in nature, and aimed at easy targets. The report also found that more than 70% of attacks exploited known vulnerabilities that had patches available.
The recent breach at Equifax was caused by a known vulnerability in the popular Struts web framework library, when uploading files. It took Equifax at least two weeks after the attack to discover the data breach and this was almost four months after the exploit had been made public. Automated alerting on known exploits could have prevented this catastrophic security hole.
This post shows an automated way to check your third party library dependencies to ensure your site does not become a victim to these opportunistic attacks.
We will use the dependency checker provided by OWASP. This example shows integration with a Maven build where the check is run against every build during the verify stage. The first run will take a while as it has to download the entire vulnerability database. Subsequent runs will have this cached and so will run much faster.
Gretchen Rubin says a useful way to think about people’s behavior is by considering how willing they are to meet or resist expectations on them. Expectations can either be external, like your boss asking for a project to be completed or internal, like exercising regularly.
From these she identifies the four combinations labelled as The Four Tendencies.
External Expectation
Internal Expectation
Upholder
Questioner
Obliger
Rebel
Meets Resists
This could provide you with more empathy when considering your colleagues, friends or family and make you a more effective communicator. Maybe try thinking about members of your software development team and which tendency they seem to exhibit.
Achieving PCI Compliance can be a rather onerous ongoing commitment. The first thing you will have to show is your architecture in the form of a network diagram together with a data flow diagram showing the routes where credit card data is transmitted. The more complex the architecture the more work involved in making it PCI compliant. So what can you do to mimise the amount of effort? Well your first thought should be around minimising the scope that falls under PCI compliance. This can be done by isolating only the components requried for payments and moving everything else outside of this scope.Once this is done you should then think about how to implement the system that will be in scope for compliance and this is what I want to talk about in this post.
The key to easier PCI compliance of YOUR system is to offload as much as possible to other providers and by other providers I mean Cloud hosting providers like AWS and GCP who’s platforms hare already attained PCI compliance.
In this example I’m going to use AWS. I’m going to compare two architectures, one deploying your application on EC2 instances and the other using Lambda as our serverless facilitator.
Lets take a simple application that takes credit card details from customers over the phone line and uses Paypal payment gateway to process the payment.
High level network diagram
If we ignore the telephony section of the data flow to keep things simple in this illustration then these are the architectures that we have to produce in each case
Traditional Architecture
Network diagram for traditional architecture
AWS Components used
VPC
public subnets
private subnets
Internet gateway
NAT gateway
Two Availability zones
Internet Gateway
Bastion host for SSH
Security groups
ACLs
Route tables
S3 buckets for Cloudwatch logs
Serverless Architecture
Network diagram for serverless architecture
AWS Components used
Lambda (using default VPC)
API gateway
S3 buckets for Cloudwatch logs
It’s pretty clear how much simpler the serverless architecture is.
Next we’ll see how some of the PCI requirements are met by each architecture and especially how must of the compliance responsibility is handed over to AWS when using the serverless solution.
How each architecture meets PCI requirements – traditional versus serverless
PCI requirement
Traditional Architecture
Serverless Architecture
Harden operating system
Hardened AMIs, remove unused applications, lock down ports
No instances (AWS takes care of runtime)
Incoming Firewall
DMZ to prevent unauthorized access, Security Group on VPC
Lambda comes with default VPC
Outoing internet access
Internet gateway, NAT gateway, Security groups and/or ACLs
Default Lambda VPC has outgoining internet access
Do not provide direct access to instances
Use a bastion host to allow SSH access
No Instances, so no SSH required
By going serverless we are able to totally ignore the following requirements:
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programsg